replaced FRP with RP in README title

[flatmap13]

Mentioning "Functional Reactive Programming" causes confusion and misconception.
I think it's better to simply stick with "Reactive Programming".

[flatmap13]

Well, that's interesting. This PR only removes one word from the README file...

[benjchristensen]

Can you provide supporting reasoning on this?

I'm likely fine with the change, but please share your reasons (and I'm aware of the debate over "behaviors", FRAN, etc and the inability of computer scientists to agree). People argue over "reactive programming" too since all of these are generic words used for different things over the decades.

[flatmap13]

The original idea of Functional Reactive Programming (FRP) is to model differential equations in a functional language. A rather simplified characterization of FRP is that it is a programming paradigm involving datatypes that represent continuous values, typically 'over time'. The complete history (past, present and future) of values has a first class representation in the FRP paradigm. In contrast, Rx concerns itself with Observable streams of asynchronous events, which are time discrete. Whereas in FRP one can ask for the value of some entity at a specific moment in time, this is clearly not the case in Rx. In other words, streams in FRP model (continuously) varying values, whereas streams in Rx are just collections.

[ghost]

then (if needed at all) I would distinguish "discrete reactive programming"
from "continuous reactive programming"
(like you can have discrete random variables and continuous random
variables)

anyway: As far as the programming paradigm is concerned: I think that the
Rx approach is clearly a functional one

On Mon, Apr 14, 2014 at 8:57 PM, Georgi Khomeriki
notifications@github.comwrote:

The original idea of Functional Reactive Programming (FRP) is to model
differential equations in a functional language. A rather simplified
characterization of FRP is that it is a programming paradigm involving
datatypes that represent continuous values, typically 'over time'. The
complete history (past, present and future) of values has a first class
representation in the FRP paradigm. In contrast, Rx concerns itself with
Observable streams of asynchronous events, which are time discrete. Whereas
in FRP one can ask for the value of some entity at a specific moment in
time, this is clearly not the case in Rx. In other words, streams in FRP
model (continuously) varying values, whereas streams in Rx are just
collections.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1036#issuecomment-40404329
.

__~O
-\ <,
()/ ()

reality goes far beyond imagination

[benjchristensen]

@GeorgiKhomeriki Thanks for your explanation and @LucDupAtGitHub for getting involved.

Fundamentally the problem I see is that very specific meanings were given to very generic words within a niche of the industry and now natural use of the same term by a broader audience is being declared as wrong.

If one takes "async/reactive" programming and combines it with a "functional" programming style and gets "functional reactive" code suddenly you step on the niche definition otherwise known as FRP which is specifically identified with "continuous values".

Thus, if someone were to use "reactive functional" to describe Rx instead of "functional reactive" there would be no issues even though it's just an awkward reordering of the words!

The term "reactive programming" itself isn't very helpful either, as imperative callback hell is also reactive programming. It's actually similar to how "object oriented programming" means different things in different languages that claim to implement OO but each in their own style. Therefore, saying Rx is not "functional reactive programming" comes across as if one particular implementation of async programming (say imperative listeners) declared to others that they can't be "reactive" because they claimed the word.

Considering all of this, and the fact that "reactive programming" is not itself descriptive enough, what should "reactive programming" (push based) done with a "functional style" (higher order functions, avoidance of state and mutability, composition, etc) be called?

[ghost]

I fully agree with Ben's arguments

remember I wrote "if needed at all" (almost implicitly meaning "btw: not as
far as I am concerned")

in fact, more generally, it mostly makes more sense to
slightly abuse common known vocabulary than to
inventing your own vocabulary

for example: Try[Z], although it has a flatMap method, is not really a monad
(it does not satisfy the monad laws) but hey, why would we not call it a
monad
in the informal way instead of inventing a new name [ which one (?)] ?
ok, Try[Z] can be turned into an applicative functor
(satisfying the applicative functor laws),
but afaik one of the goals of Try[Z] is to "fail fast" and
not to "fail slow" and somehow accumulate error messages

so let us stick to Functional Reactive Programming

just my 2 cents

Luc

On Tue, Apr 15, 2014 at 12:32 AM, Ben Christensen
notifications@github.comwrote:

@GeorgiKhomeriki https://github.com/GeorgiKhomeriki Thanks for your
explanation and @LucDupAtGitHub https://github.com/LucDupAtGitHub for
getting involved.

Fundamentally the problem I see is that very specific meanings were given
to very generic words within a niche of the industry and now natural use of
the same term by a broader audience is being declared as wrong.

If one takes "async/reactive" programming and combines it with a
"functional" programming style and gets "functional reactive" code suddenly
you step on the niche definition otherwise known as FRP which is
specifically identified with "continuous values".

Thus, if someone were to use "reactive functional" to describe Rx instead
of "functional reactive" there would be no issues even though it's just an
awkward reordering of the words!

The term "reactive programming" itself isn't very helpful either, as
imperative callback hell is also reactive programming. It's actually
similar to how "object oriented programming" means different things in
different languages that claim to implement OO but each in their own style.
Therefore, saying Rx is not "functional reactive programming" comes across
as if one particular implementation of async programming (say imperative
listeners) declared to others that they can't be "reactive" because they
claimed the word.

Considering all of this, and the fact that "reactive programming" is not
itself descriptive enough, what should "reactive programming" (push based)
done with a "functional style" (higher order functions, avoidance of state
and mutability, composition, etc) be called?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1036#issuecomment-40426315
.

__~O
-\ <,
()/ ()

reality goes far beyond imagination

[headinthebox]

From a historical perspective, I would not say that Rx comes from a "functional core", the goal was to deal with asynchronous data streams, like iterable but then push-based. One may even say Rx is rather imperative since it makes concurrency and time explicit using schedulers (which generalize Java executors) :-)

I carefully avoid mentioning the word FRP in the context of Rx because, in the Haskell world, it refers to a very specific semantic model of time-varying values. Absolutely nothing wrong with that, but totally different from the design decisions behind Rx, despite the fact that both systems have higher-order functions like map and filter.

Comparing Rx and FRP is like comparing JavaScript and C++. While there are plenty of superficial correspondences, both use curly braces and semicolons, the semantics are vastly different. Interestingly, nobody seems to get confused between C++ and JavaScript, but often people do get confused about what Rx offers when they hear the word FRP to describe it.

Unfortunately, the word reactive is quickly losing its proper meaning, like agile. My original use of reactive is very precise (and simple) http://en.wikipedia.org/wiki/Reactive_system "A reactive system is a system that responds (reacts) to external events." and matches precisely what an Observable[T] is.

[benjchristensen]

I'm going to change it to "RxJava: Reactive Extensions for the JVM" since there is absolutely nothing anyone can complain about with that since Rx == Reactive Extensions.

[ghost]

Hi,

sorry for slightly abusing this mailing list for an announcement

I am responsible for the JVM languages track
and also involved in the JavaSE track
of Devoxx 2014

I would like to remind you that this is an important conference
for which you can propose a talk (+/- 10 days left)

[ this one is for Ben Christensen ]

Ben, if you wish, I propose you as an invited speaker

thanks a lot

Luc Duponcheel

__~O
-\ <,
()/ ()

reality goes far beyond imagination