Introduction to Reactive Programming
gist.github.com
Introduction to Reactive Programming
1–10 of 34 posts
Re: Introduction to Reactive Programming
#2[deleted]
Re: Introduction to Reactive Programming
#3> "Reactive Manifesto sounds like the kind of thing you show to your project manager or the businessmen at your company."
> "FRP is programming with asynchronous data streams."
So, is Akka reactive or not?
Re: Introduction to Reactive Programming
#4> "FRP is programming with asynchronous data streams."
Maybe, if you drop the F. For clarification on FRP there was a great talk at strangeloop this year: http://www.youtube.com/watch?v=Agu6jipKfYw
Re: Introduction to Reactive Programming
#5This appears to be perhaps describing "reactive programming" as that term is used in practice, but FRP is actually something significantly more constrained.
The term was, to my understanding, invented by Conal Elliott shortly after his work with Fran. To his mind, FRP is defined as describing synchronous, continuous signals in a language with denotational semantics that clearly suggest those signals. "Events" are included in the denotational model in order to consider signals which change "infinitely quickly".
It turns out that these programs are usually executed using synchronous or even asynchronous event passing networks, but this should be considered an implementation detail alone. Further, implementation events are not the same as FRP "Events".
Typically, to my understanding, things in the "reactive extensions" family of code are not FRP nor are intending to be. They are influenced by Elliott's woork, I'm sure, but they tend to describe effectful, asynchronous event-passing networks directly. Eric Meijer has a talk about this [0].
So it is certainly reasonable to describe "reactive programming" using this mental model, although it turns out that "reactive programming" is sometimes avoided as a term. I think the reason is two-fold: (1) "functional" is kind of sexy today and (2) "reactive programming" has become incredibly diluted as a term and it's difficult to really understand what anyone might be talking about any more.
I think the first reason is compelling if a bit cheap, but the second reason should be a cautionary story to misusing the term "FRP". If it goes the way of "reactive" we will have lost even more capability to speak to one another precisely.
[0] http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key...
Re: Introduction to Reactive Programming
#6For another take on Reactive Programming from Erik Meijer, check out "Duality and the End of Reactive" [1] (video).
I watched it just last night and found it very thought provoking (so much that I stole some of the concepts to create transduce-async [2] this morning).
[1]: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key... [2]: https://github.com/transduce/transduce-async
Re: Introduction to Reactive Programming
#7Previous discussion on this article:
Re: Introduction to Reactive Programming
#8How similar is this to Flow Based Programming by Paul Morrison?
Re: Introduction to Reactive Programming
#9How similar is this to Flow Based Programming by Paul Morrison?
If fbp is a form of dataflow programming, I think you could say it is reactive..
I would try to separate data flow from the FRP style that reifies the time step into first-class values .e.g. w/ "signals" or "behaviors", or from the "arrowized" forms of FRP
Re: Introduction to Reactive Programming
#10The problem I always run into with reactive programming is that of glitches, and stuff being recomputed more often than necessary.
Glitches can appear when, for example, two inputs of a certain "functional box" change almost at the same time. When input 1 changes, the output changes, and then when input 2 changes, the output changes again, thus resulting in lots of superfluous computation in the chain that follows this output.
The nice part about reactive programming is intended to be that stuff gets recomputed incrementally, but in practice this often does not happen!