@Edward de Jong / Beads Project What do you think about Rx and Reactive systems (FRP)?

FRP is not the same as Rx. FRP is pure functional programming (functions are pure and there is no shared mutable state), whereas ReactiveX is imperative and object-oriented (Observable methods like onNext, onError, onCompleted have side effects, which requires shared mutable state). The ReactiveX web site says this:

It is sometimes called “functional reactive programming” but this is a misnomer. ReactiveX may be functional, and it may be reactive, but “functional reactive programming” is a different animal. One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX operates on discrete values that are emitted over time. (See Conal Elliott’s work for more-precise information on functional reactive programming.)

@Doug Moen Yeah I am aware of that, but based on the following blog post I felt its OK to refer as FRP to that. (https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-just-did-d5ffaa23973b#.xym3mzpyn) The following is a quote from the blog: The article says: What are we going to do? Ironically, I’ll actually take Conal Elliott’s advice he let slip in a StackOverflow answer:

To reduce confusion, I would like to see the term “functional reactive programming” replaced by the more accurate & descriptive “denotative, continuous-time programming” (DCTP)

Original FRP becomes DCTP and FRP can be vaguely used for functionally-composable signals.

I find these terms are relatively meaningless. All modern programs ultimately resolve to code that runs on a mutable state CPU using either ARM or Intel instruction sets, which only have arithmetic, branching, call/return and misc. housekeeping instructions. The function (subroutine) has been the building block on which all towers have been built since almost day 1. At the end of the day we are all using functions (subroutines) to achieve leverage, and most of the systems we are building respond to user input, hopefully with some snap. We used to call it graphical interactive software, but i guess the priests who try to make it mysterious fall in love with jargon. What is more interesting, is are we headed towards a world of interchangeable parts? How much of Github is actually usable by you or I on a daily basis? Or is is just billions of lines of rotting code of unknown quality, written in a motley collection of languages, all using different data models which make it impossible to snap a piece from one program into another? How much sharing are we achieving between Desktop, Mobile, and Web products? How many thousand completely incompatible versions of a simple line plotting program have and continue to be built? To me, ease of building, reading and maintenance of of paramount concern, and to that end a more declarative style of language is clearly superior as code that doesn't execute is intrinsically more reliable than code that runs. How many times have you puzzled over a self-defining constant versus untangling a tortuous execution path. Branching (IF statements) is the real enemy, because each one doubles the number of potential paths through your code. I wouldn't mind deep nesting in Java if there was no branching, but when you go 50 levels deep in a java program and each level has a branch or two, you are talking about 2^50 different potential paths.

Well, there's another active thread I'm on where we are using the name FRP to refer to Conal Elliot's original FRP, and it's kind of confusing to have the same word mean different things within this forum. Also, if I want to find implementations of Elliot's FRP using Google, then the term "DCTP" is useless: virtually nobody uses it. All those Haskell FRP libraries call themselves "FRP".

@Doug Moen Thanks for the info, I think I’ll go with Haskell FRP and Rx in future 🙂

One distinction/temsion is between continuous signals and discrete event streams.