13 ms·

An Introduction to Reactive Programming

455 points by staltz 12y ago

anaisbetts 12y ago
A lot of people have reported that they grok Rx* much better once they watch this talk I gave at http://vimeo.com/43659034 http://vimeo.com/43659034 - if you understand map / reduce / filter as applied to lists (in C#, "Select / Aggregate / Where"), Reactive Programming isn't too hard to understand if properly explained.
- seanmcdirmid 12y ago
  Rx isn't really reactive programming so much as slinging event streams around, there is much more to reactive programming than that (e.g. ReactJS is based on something completely different).
  - vjeux 12y ago
    Before we launched React we had a big discussion as whether we should change the name or not. React is completely different from everything that's called "reactive programming" and we were afraid to cause confusion.
    - tel 12y ago
      I personally find it causes a lot of confusion. Generally the term "reactive" has become very buzzwordy and meaningless if late. I think Meijer's talk just touches on the beginnings of it.
      - Paradigma11 12y ago
        I know the stream based RX and several continuous/events based FRP implementations and their associated problems. Are there other interesting approaches?
        tel 12y ago
        I think my general feeling is that "there is no true reactive", but it's trendy to be responsive in that you have a system which behaves in soft or hard real time. There are a lot of components of such a system and lots of ways to organize it, but no clear feeling for which is best. At the end of the day it always feels like fighting between general purpose programming languages. Nobody can win, everyone optimizes for different things, and broad terms are useless except for marketing.
        seanmcdirmid 12y ago
        Well, there is also managed time. http://research.microsoft.com/apps/pubs/default.aspx?id=211297 http://research.microsoft.com/apps/pubs/default.aspx?id=2112... Constraint and logical systems like Bloom also qualify in dealing with change (the underlying meaning if "react"). The nice thing about FRP was that it went way beyond event streams, which is why Rx is so disappointing (which is just about event streams, react + Rx is sort of FRP).
    - reflectiv 12y ago
      I always have to stop and check which 'react' something is talking about lately every time. From my perspective it is causing confusion...and I don't think I am alone.
  - mattpodwysocki 12y ago
    It's funny how people think Reactive is new as we've been around since 2007 in different forms with a big release back in 2009 (so five years ago). I would disagree as being the primary author of RxJS as well as a contributor to all other flavors that it's just about slinging around events. It's more than just that as we have to deal with failure, load, etc.
    - seanmcdirmid 12y ago
      Basically, Rx was a huge step back from FRP by getting rid of behaviors and focusing just on events. So ya, you get to do things about those streams, but none of the fancy continuous binding computations that could be done in FRP (and to a lesser extent, React).
      - mattpodwysocki 12y ago
        Can you give some examples? I'm failing to see how this was a step backwards.
        seanmcdirmid 12y ago
        The classic one would be C = A + B where A and B change continuously over time, causing C to change continuously to match the current values of A and B. Change propagation then becomes a core part of push-based FRP (pull based with just resemble), whereas in Rx you have to manage the change streams for A and B manually.
        bad_user 12y ago
        C = A + B in Rx is just a combination of 2 observables. One way of doing that is with "combineLatest": A.combineLatest(B).map((a,b) => a + b) Of course, you may want to cache the last emitted value for "a+b", or a default value in case no items were emitted yet, something that would be a hot multicast observable, roughly: A.combineLatest(B).map((a,b) => a + b) .multicast(BehaviorSubject(default)) And the underlying framework can optimize for this use-case, with shortcuts and whatnot. In Scala, nothing would prevent you from having a sexy macro, akin to Scala-Async. All that matters is the underlying abstractions are Observable (the producer, characterized by its subscribe method), the Observer (the consumer, which is really a single function split in 3) and the communication protocol between them. I don't see that as a regression, I see it as the foundation - in the end, no matter what you make of behaviors, it's still a producer/consumer pattern. Actually my problem with the original Rx implementation is very different. I'm also working on an Rx redesigned implementation for Scala, with back-pressure baked in by design in the protocol [1]. This is because when events are passing asynchronous boundaries, you can have streams that are producing more data than consumers can process and (compared with other abstractions for processing streams of data, like Iteratees) the consumer doesn't signal demand back to the producer. And this issue becomes even more relevant when events are sent over the network. [1] https://github.com/monifu/monifu/wiki/Rx-Contract-and-Design-Guidelines https://github.com/monifu/monifu/wiki/Rx-Contract-and-Design...
- yvdriess 12y ago
  This was also a good eyeopener, from the man himself: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote-Duality http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key...
_pmf_ 12y ago
> So you're curious in learning this new thing called (Functional) Reactive Programming (FRP). Chaining is the new goto. Abused, it causes deeply anti-modular, temporally coupled code, which is really really ugly to maintain (good thing rockstar ninja programmers only need to think two weeks ahead).
- yvdriess 12y ago
  Reactive programming (languages) are supposed to give you a way to deal with such complexity, for instance by solving the inversion of control problem. This really is not chaining events together, just as structured programming is not just chaining todo's together.
- Ixiaus 12y ago
  You are confusing "chaining" with "composition". The two have fundamental differences. This confusion is understandable though because languages without a strong type system make true composition very loose (the exception being stack based languages, I think). Javascript is a poor language for composition; stream programming is uniquely suited to strongly typed languages with denotational semantics that make function composition natural and you'll probably be seeing much more of Elm and other Haskell to Javascript compilers taking the stage for this.
- mattpodwysocki 12y ago
  In this case, it's no more abuse than Ruby's Enumerable, JavaScript's Array#extras, and of course .NET's LINQ. How is this abuse exactly?
peaton 12y ago
This is super helpful. The example with the multi-click stream is pretty impressive as a demo. Is anyone familiar with the Elm[1] language/library that compiles to JS? Does it facilitate good FRP practice? Or are there any better libraries/languages out there? I've just seen a lot of Elm when I've google FRP in the past. (Followed closely by Haskell.) [1] http://elm-lang.org/ http://elm-lang.org/
- seanmcdirmid 12y ago
  Neither Rx nor Elm are FRP. If you want FRP, look at Conal Elliott's work.
  - peaton 12y ago
    Will do. Thanks for the pointer. Do you have any suggestions offhand?
    - seanmcdirmid 12y ago
      Start at the beginning: http://conal.net/fran/tutorial.htm http://conal.net/fran/tutorial.htm Warning: FRP is much more purest than Rx (which is just data flow) or Elm (which is more FRPish but asynchronous). You probably don't want FRP but something more pragmatic like the fore mentioned systems.
      - newgame 12y ago
        From what I understand, although Conal Elliot coined the term FRP first in a relatively narrow sense, today the term FRP is used much more freely to describe reactive programming using functional building blocks (especially combinators like map, filter etc.). There are some nice papers that give an overview of the FRP landscape. “A Survey on Reactive Programming”: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.416.1589&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.416... “Towards Reactive Programming for Object-oriented Applications”: http://www.guidosalvaneschi.com/attachments/papers/2014_Towards-Reactive-Programming-for-Object-Oriented-Applications_pdf.pdf http://www.guidosalvaneschi.com/attachments/papers/2014_Towa...
CmonDev 12y ago
"Javascript is the most familiar language out there at the moment" Will people ever stop using this reasoning? Why not pick the best/better language instead?
- jrajav 12y ago
  Because the goal here is not to write the most efficient and most maintainable code, but to demonstrate a new concept. Familiarity and availability are more relevant in this case than "best language," however you'd measure that.
  - derefr 12y ago
    Hmm. Java might be known by more, if just from the fact that those who take an introductory CS course as an elective in another major will get their lessons in it. But, as a lingua franca, it sucks even worse. Mind that term, actually: while French itself was just an average European language, it was handy, for political reasons, for diplomats of all stripes to pick up—and somewhat easy, presuming you had studied texts in Latin. JS is much the same: a lot of us might not prefer it when writing our own code, but we can all certainly read it, given its ALGOL derivation, and it's certainly more pithy than, say, C, for communicating the kind of concepts we need to communicate (like FRP.)
    - Terr_ 12y ago
      > But, as a lingua franca, it sucks even worse. Mind that term, actually: while French itself [...] Mind that term even more, because despite the similar "fr--" sound, it does not actually denote the French language. "Lingua franca" is actually an Italian term for "Frankish language", during a time (post-middle-ages) when "Franks" often referred to Western Europe in general. While French is an example of a language which fit the definition for a period of time, it is not the source of its name.
- collyw 12y ago
  Agreed.
- 12y ago
shadytrees 12y ago
We use ReactiveCocoa [0] extensively at work and can't recommend it highly enough [1]. (Although admittedly KVO makes Cocoa almost the ideal platform for reactive programming.) [0]: https://github.com/ReactiveCocoa/ReactiveCocoa https://github.com/ReactiveCocoa/ReactiveCocoa [1]: http://ianthehenry.com/2014/5/4/kvo-101/ http://ianthehenry.com/2014/5/4/kvo-101/
nemanja 12y ago
I also found Martin Odersky's Principles of Reactive Programming Coursera class [1] very helpful. [1] https://class.coursera.org/reactive-001 https://class.coursera.org/reactive-001
- X4 12y ago
  I and a friend attended to the class and read several papers, but all you learn are concepts, tools, paradigms and implementations. There is no "formula" for creating FRP, it's very generic although highly specific on monads, (applicative) functors, monoids, etc. So definitively worth a shot, if you want to learn everything around FRP.
alipang 12y ago
Here's an introduction to Bacon.js, implementing a game with eventstreams, if anyone is interested in more. http://philipnilsson.github.io/badness/ http://philipnilsson.github.io/badness/
newgame 12y ago
If you're interested in FRP in terms of GUI programming, as described in the linked article, you should definitely checkout ReactFX [0], an FRP library for JavaFX, and also the author Tomas Mikula's blog [1] that contains very convincing examples of FRP's usefulness for real UI tasks [2]. [0]: https://github.com/TomasMikula/ReactFX https://github.com/TomasMikula/ReactFX [1]: http://tomasmikula.github.io/blog/ http://tomasmikula.github.io/blog/ [2]: http://tomasmikula.github.io/blog/2014/04/25/combining-reactfx-and-asynchronous-processing.html http://tomasmikula.github.io/blog/2014/04/25/combining-react... If you are confused by the term FRP and its different interpretations, I tried to summarize them in a stackoverflow answer: http://stackoverflow.com/questions/22795062/is-it-possible-to-translate-the-mario-example-from-elm-to-either-pure-javafx-or/23909098#23909098 http://stackoverflow.com/questions/22795062/is-it-possible-t...
wolfwyrd 12y ago
Lee Campbell's book/site is a good place to start - http://introtorx.com/ http://introtorx.com/
platz 12y ago
Some additional overview of different reactive approaches: http://www.slideshare.net/deanwampler/reactive-design-languages-and-paradigms http://www.slideshare.net/deanwampler/reactive-design-langua... https://www.youtube.com/watch?v=4L3cYhfSUZs https://www.youtube.com/watch?v=4L3cYhfSUZs * responsive (somewhat hand-wavy - basically, don't block on IO) * scalable (hard to be scalable - many different approaches) * resilient (hard to be resilient - erlang is king here) * event-driven (it's hard to not be event-driven these days)
- mattpodwysocki 12y ago
  The Reactive Extensions covers all of those particular topics quite well, in terms of responsive to failure, responsive to events, responsive to load etc. We cover that a bit in our repository with the Reactive Manifesto: https://github.com/Reactive-Extensions/RxJS https://github.com/Reactive-Extensions/RxJS And I've even covered it at StrangeLoop 2013: video: http://www.infoq.com/presentations/rx-event-processing http://www.infoq.com/presentations/rx-event-processing slides: https://github.com/Reactive-Extensions/StrangeLoop2013 https://github.com/Reactive-Extensions/StrangeLoop2013 As well as FutureJS: video: https://www.youtube.com/watch?v=zlERo_JMGCw https://www.youtube.com/watch?v=zlERo_JMGCw slides: https://github.com/Reactive-Extensions/FutureJS https://github.com/Reactive-Extensions/FutureJS
Paradigma11 12y ago
Names can change over time but here is how i recall it: FRP is a development based on the work of conal elliott: http://conal.net/ http://conal.net/ It's main characteristic is that there is a continuous (pull)aspect. Since many interesting domains are not predominantly continuous he and many others had to add a discrete event based component. Rx is a stream based technology (push). Basically it is a dataflow library with modern functional programming syntactic elements. It does not have a continuous aspect and as such it is not FRP. By treating Rx as something new we are depriving our self of the dataflow and structured programming knowledge.
swanson 12y ago
I've struggled to grok FRP in the past - I hear lots of smart people trumpeting it, but I haven't been able to wrap my head around it. This tutorial was great and I was following along right until it got to the part about modeling the suggestions as streams (https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#modelling-the-3-suggestions-with-streams https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#modellin...). That was where everything went haywire for me - my brain doesn't want to think about those UI elements as streams and I instantly tune out and think "this doesn't make sense". I'm curious if anyone else also got stuck at that same part, as well as if anyone has suggestions/ideas for breaking past this mental barrier? Is there a different way of solving the same problem (that might make more sense to me)?
- staltz 12y ago
  Hi, can you make that question on the gist so that the discussion persists there? I'd be glad to try to fill in the missing mental bits there.
  - swanson 12y ago
    Sure thing :)
- skybrian 12y ago
  You can think of an animation as a stream of frames; this is how video is implemented. It especially makes sense for video games that typically have a game loop that renders the screen at 30 or 60 frames per second. Similarly, a UI element can be thought of a a stream of snapshots. Each time you render the UI element, you're creating another frame. In Elm, an entire UI is a stream of frames. (The type is Signal Element.) When you put Elements together into a tree, you're just constructing a single frame of an animation. Unfortunately, a UI in Elm is not composable in the same way as a traditional UI. The model, appearance, and behavior of a UI element are handled by different parts of the program. This is sometimes good (model and appearance are cleanly separated) but it's unclear whether we can build large applications this way. It's one of the reasons why Elm is still an experimental language.
TacticalCoder 12y ago
Great article but there's something I'd like to understand: the article talks about FRP yet writes "(Functional) Reactive Programming" with "functional" between parentheses, why? Is the 'F' in FRP the same 'F' as when people say that, for example, Haskell and Clojure are FP languages? Does FRP use the notion of "functions" which are closer to the mathematical definition of a function? For example does FRP try to avoid state and mutable data as much as possible and do the same inputs always lead to the same output? Or is it called "functional" simply because it allows to use things like map/reduce/filter? If it is "really" functional, I take it it's quite deterministic: can you then take all these streams of events and "replay" them at will, always ending up in the same intermediary state and, eventually, in the same final "state"? If that's the case, then it's the next thing on my "to learn" list :)
- staltz 12y ago
  > There's something I'd like to understand: the article talks about FRP yet writes "(Functional) Reactive Programming" with "functional" between parentheses, why? This comment https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#comment-1255003 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#comment-... and this discussion https://twitter.com/ReactiveX/status/483625917491970048 https://twitter.com/ReactiveX/status/483625917491970048 > If it is "really" functional, I take it it's quite deterministic: can you then take all these streams of events and "replay" them at will, always ending up in the same intermediary state and, eventually, in the same final "state"? Yes. See this http://debug.elm-lang.org/ http://debug.elm-lang.org/
canterburry 12y ago
How is this different from complex event processing (CEP)? High frequency trading has been using this from day 1. The real trick is working with historical events and fetch them from disk, otherwise your reasoning time window is restricted to whatever fits in RAM.
- mattpodwysocki 12y ago
  Using Rx, you can certainly do CEP as we have buffer and window operators, and the ability to so groupBy and other complex operators. For example we have one that analyzes stock streams https://github.com/Reactive-Extensions/NDC-Oslo-2014/blob/master/demos/WinJS/client/pages/stocks/stocks.js https://github.com/Reactive-Extensions/NDC-Oslo-2014/blob/ma...
  - canterburry 12y ago
    So, are you saying Rx is the superset and CEP is a subset of Rx functionality? What can you do in Rx that you can't do in CEP?
    - mattpodwysocki 12y ago
      I would certainly say that Rx has a superset of the operators in standard CEP which largely deals with buffers and windows, yes. In addition, we have time-based join and group join behavior, join calculus eg: Rx.Observable.when( stream1.and(stream2).then(...), stream3.and(stream4).then(...) );
eridius 12y ago
I thought this was a decent tutorial, but I'm a bit annoyed at the double-click bit. Yeah sure, you can implement some form of double-clicks in 4 lines of code, but it behaves badly. And since the tutorial glossed over it, I have no idea if this is just because the author doesn't realize they implemented a really bad click system, or because it takes a lot more than 4 lines of code to do it right and the author didn't like that so chose to ignore it. Notably, the single-click stream has a built-in 250ms delay before the click is fired. That's bad. Similarly, the double-click has a built-in 250ms delay even if the user clicks twice within 100ms. In fact, it's not just a 250ms delay from the first click; it's a 250ms delay from the last click before it finally emits the event. That's a completely unusable way of doing clicks. If that's how you do clicks in FRP, then that's a serious issue with FRP. I have to assume there's a better way, and I'd really like to see it. The correct behavior is to emit a click event immediately upon a click, but to remember recent history and associate a click count with the event based on whether there are recent clicks. So if I click 7 times in a row at sufficient speed, I should get a click event for every single one, getting 1x through 6x clicks before finally getting the 7x click on the last one.
- staltz 12y ago
  Sure, you can do that. If it's not how you want it to be, just tweak it. http://jsfiddle.net/staltz/U2j4D/8/ http://jsfiddle.net/staltz/U2j4D/8/
  - eridius 12y ago
    Thank you, that behaves a lot better. It seems a bit odd that the multiClickStream emits a `0` 200ms after the last click, but I guess you can add the filter to the multiClickStream directly and let the button clear its own text a different way. http://jsfiddle.net/U2j4D/17/ http://jsfiddle.net/U2j4D/17/ So more than 4 lines of code, but I'm glad to see it's quite doable.
  - Groxx 12y ago
    Interesting implementation - I'm just starting to poke into reactive, things like this help me think differently :) That said, this is not the same thing as a double-click handler. This is a single click plus a double click when you click twice. Typically when you do double-click handlers you delay single-click until it's a confirmed not-double-click. I think I have an idea of how to make that work here, but do you have a preferred approach?
X4 12y ago
There is one thing that really bothers me, I've not found a single a mathematical formula that defines FRP. The closest thing I've found was the "Denotational Semantics" showing the logic behind, which is quite lenghty and leaves a lot of room for variations. I hate descriptions full of buzzwords that, when you look at it closely have really nothing to do with FRP, but are mere tools that help realizing it. Is there someone who can explain us scholars how FRP can be noted down formaly? Even a link to a page of a paper that shows the formula would be enormously useful. I'll put all the good papers that I've found in the footnoes. -------- 　The following are a few of the good papers on FRP (ordered by subj. quality). I've read the Elm paper, but it's vague despite having a lot of maths in it. What it really decribes is not FRP, but Elm (also it's not exactly FRP). 　[1] https://blogs.janestreet.com/breaking-down-frp/ https://blogs.janestreet.com/breaking-down-frp/ 　[2] Higher-Order Functional Reactive Programming without Spacetime Leaks - https://www.mpi-sws.org/~neelk/simple-frp.pdf https://www.mpi-sws.org/~neelk/simple-frp.pdf 　[3] An Axiomatic Semantics for Functional Reactive Programming - http://www.wpi.edu/Pubs/ETD/Available/etd-042908-133033/unrestricted/cking.pdf http://www.wpi.edu/Pubs/ETD/Available/etd-042908-133033/unre... 　[4] Push-pull functional reactive programming - http://conal.net/papers/push-pull-frp/ http://conal.net/papers/push-pull-frp/ 　[5] Categorical Semantics for Functional Reactive Programming with Temporal Recursion and Corecursion - http://www.cs.bham.ac.uk/~pbl/msfp2014/catsemfrp.pdf http://www.cs.bham.ac.uk/~pbl/msfp2014/catsemfrp.pdf 　[6] Completeness of Conversion between Reactive Programs for Ultrametric Models - http://www.cs.le.ac.uk/people/fdv1/fdv1/Distribution/SeveriDeVriesTLCA2013.pdf http://www.cs.le.ac.uk/people/fdv1/fdv1/Distribution/SeveriD... 　[7] Fair Reactive Programming - http://www.cs.mcgill.ca/~acave1/papers/fair-reactive.pdf http://www.cs.mcgill.ca/~acave1/papers/fair-reactive.pdf 　[8] A Survey on Reactive Programming - http://soft.vub.ac.be/Publications/2012/vub-soft-tr-12-13.pdf http://soft.vub.ac.be/Publications/2012/vub-soft-tr-12-13.pd... 　[9] Signals, Not Generators! - http://www.ioc.ee/~wolfgang/research/tfp-2009-slides.pdf http://www.ioc.ee/~wolfgang/research/tfp-2009-slides.pdf 　[10] http://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language#5878525 http://stackoverflow.com/questions/5875929/specification-for... 　[11] http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming/1030631#1030631 http://stackoverflow.com/questions/1028250/what-is-functiona... The bad thing about all those papers is that a) you need to know Category Theory, b) Temporal Logic, c) Denotational Semantics d) (and optionally Henkin and Ultrametric Models) Unfortunately I'm not yet that smart :( hope someone can bring clarity into FRP Sorry for the ugly footnote, that's the best I got using HN's formatting capability. Update: I used unicode spaces, that fixed it.
scotty79 12y ago
If you want to learn streams the hard way try to implement any non trivial build process with gulp.js Just a warrning. Node.js had 3 versions of streams so far and some packages that implement stream functionality don't all work properly with latest version. Also two types bytestream and object stream.
- mattpodwysocki 12y ago
  Node.js streams are largely unicast, instead RxJS and related libraries can be multicast. RxJS, on the other hand has been fairly stable for quite some time now and the APIs largely haven't changed from when we first released in 2010.
heydenberk 12y ago
It looks to me like Bacon.js is the community favorite and RxJS is the corporate framework when it comes to JavaScript libraries for FRP. I'm thinking about introducing an FRP library into the frontend stack where I work — does anyone have any experience with using either of these libraries (or another) for corporate work? What did you use and how did your coworkers deal with it?
- mattpodwysocki 12y ago
  As the primary author of RxJS, I take exception to that characterization. Anyways, you should look at the performance differences between RxJS and Bacon.js. They are quite significant! https://github.com/pozadi/kefir/blob/master/test/perf/memory-results.txt https://github.com/pozadi/kefir/blob/master/test/perf/memory...
  - novaleaf 12y ago
    Hi Matt, fyi the codeplex page doesn't mention what appears to be the primary website: http://reactive-extensions.github.io/RxJS/ http://reactive-extensions.github.io/RxJS/ so you might want to get a link added....
  - heydenberk 12y ago
    I should be clear that I'm only referring to the superficial characteristics about the frameworks. Nothing about the API itself seems very corporate. Thanks for the pointer to the performance characteristics. I'm interested in differentiating factors.
steveklabnik 12y ago
I wrote a little FRP library in Ruby: https://github.com/steveklabnik/frappuccino https://github.com/steveklabnik/frappuccino
- mattpodwysocki 12y ago
  steveklabnik, still working on the Ruby port of Rx. It will get there but needs more community support.
latentflip 12y ago
To add another resource to the list, I gave an introductory talk to bacon.js and FRP last year which has similar diagrams to these which I animated with d3 if anyone'a interested: http://vimeo.com/m/68987289 http://vimeo.com/m/68987289
davexunit 12y ago
I am writing a game engine in Scheme that uses FRP. My implementation may not be robust since I'm the only user, but perhaps seeing what it can do will help someone. My implementation was heavily inspired by Elm. Blog post with screencast to demonstrate: http://dthompson.us/functional-reactive-programming-in-scheme-with-guile-2d.html http://dthompson.us/functional-reactive-programming-in-schem... Implementation details: https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2431e4d920f0b678ba:sly/signal.scm https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2... 2048 clone written in a reactive style: https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2431e4d920f0b678ba:examples/2048/2048 https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2... Reading the explanation from the Elm folks is what made things click for me: http://elm-lang.org/learn/What-is-FRP.elm http://elm-lang.org/learn/What-is-FRP.elm Edit: Also, SICP has 2 sections that describe systems that are reminiscent of reactive programming systems. A Simulator for Digital Circuits: https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4 https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.htm... Propagation of Constraints: https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.5 https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.htm...
- seanmcdirmid 12y ago
  Why not look at Gregory Cooper et. al.'s FrTime? Its the first FRP system I'm aware of for Scheme, and its quite well used in Racket. It is also a predecessor of Flapjax. http://docs.racket-lang.org/frtime/ http://docs.racket-lang.org/frtime/
  - davexunit 12y ago
    I've read some of this source, too. Thanks.
mjackson 12y ago
> FRP streams go beyond promises by allowing many returned values. This is pretty nice, and shows how FRP is at least as powerful as Promises. The fact that you can only return a single value from a promise is a feature, not a limitation. In synchronous code, you can only return once from a function. In asynchronous promise code, you can only fulfill the promise once. There's a parallel. If you want to "allow many returned values" you can just use a callback. You hardly need a "stream" for that.
- AgentME 12y ago
  A stream can be thought of like a function in a lazy language returning an array of results which aren't necessarily calculated (or available) all at once. >If you want to "allow many returned values" you can just use a callback. You hardly need a "stream" for that. Callbacks are hard to compose, may not have standard error conventions, and you can't have multiple listeners subscribe to the same thing after the fact. (Those are the same things that promises solve for async functions with a single result.) Additionally, you can stop listening to a stream and the source can know to close itself once it has no more listeners.
- klibertp 12y ago
  > In synchronous code, you can only return once from a function. Erm, have you heard a term "continuation" or "call/cc" ("call-with-curent-continuation")? Or "delimited continuations"? Or maybe even "Cont monad"? You should read on them, if you haven't - they are one of the most fundamental and fun concepts I encountered. But even without those, what you wrote here is false in the presence of generators (which are coming to JS any day now!). I'd say that returning more than once from function is actually a pretty basic technique which is widely used to implement quite a wide array of different things.
  - dllthomas 12y ago
    Or, over in C land, setjmp.
moondowner 12y ago
RxJava's wiki is also pretty good: https://github.com/Netflix/RxJava/wiki https://github.com/Netflix/RxJava/wiki
prawks 12y ago
With seemingly more emphasis being placed on complex pub-sub architectures, has there been any equivalent development of tooling to assist in visualizing/grokking an existing pub-sub application? In my experience at least, pub-sub architecture can be difficult to follow without good tooling (trying to keep all of these coexisting streams in your head when making changes, as asynchronous code is difficult to write a test suite for that could catch mistakes). This is somewhat just the nature of asynchronous programming, but there has been more and more emphasis on that as well with the popularity of highly responsive GUI applications and more computing capacity for background tasks. Aside from using Visual Studio-esque "find references" to navigate to all of the locations in a codebase where a particular event stream is subscribed to, I've yet to come across much.
moondowner 12y ago
For those searching for Rx examples, I found these: https://github.com/fdecampredon/react-rxjs-todomvc https://github.com/fdecampredon/react-rxjs-todomvc (TodoMVC implementation built on top of React + RxJS) https://github.com/eliseumds/react-autocomplete https://github.com/eliseumds/react-autocomplete (React + RxJS Autocomplete)
- mattpodwysocki 12y ago
  Yep, there are plenty of examples to be found such as those listed here: https://github.com/Reactive-Extensions/NDC-Oslo-2014 https://github.com/Reactive-Extensions/NDC-Oslo-2014 In addition, we ship a good number of samples within our RxJS repository: https://github.com/Reactive-Extensions/RxJS/tree/master/examples https://github.com/Reactive-Extensions/RxJS/tree/master/exam...
  - moondowner 12y ago
    Cool!

455 points by staltz 12y ago

A lot of people have reported that they grok Rx* much better once they watch this talk I gave at http://vimeo.com/43659034 http://vimeo.com/43659034 - if you understand map / reduce / filter as applied to lists (in C#, "Select / Aggregate / Where"), Reactive Programming isn't too hard to understand if properly explained.

seanmcdirmid 12y ago
Rx isn't really reactive programming so much as slinging event streams around, there is much more to reactive programming than that (e.g. ReactJS is based on something completely different).
- vjeux 12y ago
  Before we launched React we had a big discussion as whether we should change the name or not. React is completely different from everything that's called "reactive programming" and we were afraid to cause confusion.
  - tel 12y ago
    I personally find it causes a lot of confusion. Generally the term "reactive" has become very buzzwordy and meaningless if late. I think Meijer's talk just touches on the beginnings of it.
    - Paradigma11 12y ago
      I know the stream based RX and several continuous/events based FRP implementations and their associated problems. Are there other interesting approaches?
      - tel 12y ago
        I think my general feeling is that "there is no true reactive", but it's trendy to be responsive in that you have a system which behaves in soft or hard real time. There are a lot of components of such a system and lots of ways to organize it, but no clear feeling for which is best. At the end of the day it always feels like fighting between general purpose programming languages. Nobody can win, everyone optimizes for different things, and broad terms are useless except for marketing.
      - seanmcdirmid 12y ago
        Well, there is also managed time. http://research.microsoft.com/apps/pubs/default.aspx?id=211297 http://research.microsoft.com/apps/pubs/default.aspx?id=2112... Constraint and logical systems like Bloom also qualify in dealing with change (the underlying meaning if "react"). The nice thing about FRP was that it went way beyond event streams, which is why Rx is so disappointing (which is just about event streams, react + Rx is sort of FRP).
  - reflectiv 12y ago
    I always have to stop and check which 'react' something is talking about lately every time. From my perspective it is causing confusion...and I don't think I am alone.
- mattpodwysocki 12y ago
  It's funny how people think Reactive is new as we've been around since 2007 in different forms with a big release back in 2009 (so five years ago). I would disagree as being the primary author of RxJS as well as a contributor to all other flavors that it's just about slinging around events. It's more than just that as we have to deal with failure, load, etc.
  - seanmcdirmid 12y ago
    Basically, Rx was a huge step back from FRP by getting rid of behaviors and focusing just on events. So ya, you get to do things about those streams, but none of the fancy continuous binding computations that could be done in FRP (and to a lesser extent, React).
    - mattpodwysocki 12y ago
      Can you give some examples? I'm failing to see how this was a step backwards.
      - seanmcdirmid 12y ago
        The classic one would be C = A + B where A and B change continuously over time, causing C to change continuously to match the current values of A and B. Change propagation then becomes a core part of push-based FRP (pull based with just resemble), whereas in Rx you have to manage the change streams for A and B manually.
        bad_user 12y ago
        C = A + B in Rx is just a combination of 2 observables. One way of doing that is with "combineLatest": A.combineLatest(B).map((a,b) => a + b) Of course, you may want to cache the last emitted value for "a+b", or a default value in case no items were emitted yet, something that would be a hot multicast observable, roughly: A.combineLatest(B).map((a,b) => a + b) .multicast(BehaviorSubject(default)) And the underlying framework can optimize for this use-case, with shortcuts and whatnot. In Scala, nothing would prevent you from having a sexy macro, akin to Scala-Async. All that matters is the underlying abstractions are Observable (the producer, characterized by its subscribe method), the Observer (the consumer, which is really a single function split in 3) and the communication protocol between them. I don't see that as a regression, I see it as the foundation - in the end, no matter what you make of behaviors, it's still a producer/consumer pattern. Actually my problem with the original Rx implementation is very different. I'm also working on an Rx redesigned implementation for Scala, with back-pressure baked in by design in the protocol [1]. This is because when events are passing asynchronous boundaries, you can have streams that are producing more data than consumers can process and (compared with other abstractions for processing streams of data, like Iteratees) the consumer doesn't signal demand back to the producer. And this issue becomes even more relevant when events are sent over the network. [1] https://github.com/monifu/monifu/wiki/Rx-Contract-and-Design-Guidelines https://github.com/monifu/monifu/wiki/Rx-Contract-and-Design...
yvdriess 12y ago
This was also a good eyeopener, from the man himself: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote-Duality http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key...

_pmf_ 12y ago

> So you're curious in learning this new thing called (Functional) Reactive Programming (FRP). Chaining is the new goto. Abused, it causes deeply anti-modular, temporally coupled code, which is really really ugly to maintain (good thing rockstar ninja programmers only need to think two weeks ahead).

yvdriess 12y ago
Reactive programming (languages) are supposed to give you a way to deal with such complexity, for instance by solving the inversion of control problem. This really is not chaining events together, just as structured programming is not just chaining todo's together.
Ixiaus 12y ago
You are confusing "chaining" with "composition". The two have fundamental differences. This confusion is understandable though because languages without a strong type system make true composition very loose (the exception being stack based languages, I think). Javascript is a poor language for composition; stream programming is uniquely suited to strongly typed languages with denotational semantics that make function composition natural and you'll probably be seeing much more of Elm and other Haskell to Javascript compilers taking the stage for this.
mattpodwysocki 12y ago
In this case, it's no more abuse than Ruby's Enumerable, JavaScript's Array#extras, and of course .NET's LINQ. How is this abuse exactly?

peaton 12y ago

This is super helpful. The example with the multi-click stream is pretty impressive as a demo. Is anyone familiar with the Elm[1] language/library that compiles to JS? Does it facilitate good FRP practice? Or are there any better libraries/languages out there? I've just seen a lot of Elm when I've google FRP in the past. (Followed closely by Haskell.) [1] http://elm-lang.org/ http://elm-lang.org/

seanmcdirmid 12y ago
Neither Rx nor Elm are FRP. If you want FRP, look at Conal Elliott's work.
- peaton 12y ago
  Will do. Thanks for the pointer. Do you have any suggestions offhand?
  - seanmcdirmid 12y ago
    Start at the beginning: http://conal.net/fran/tutorial.htm http://conal.net/fran/tutorial.htm Warning: FRP is much more purest than Rx (which is just data flow) or Elm (which is more FRPish but asynchronous). You probably don't want FRP but something more pragmatic like the fore mentioned systems.
    - newgame 12y ago
      From what I understand, although Conal Elliot coined the term FRP first in a relatively narrow sense, today the term FRP is used much more freely to describe reactive programming using functional building blocks (especially combinators like map, filter etc.). There are some nice papers that give an overview of the FRP landscape. “A Survey on Reactive Programming”: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.416.1589&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.416... “Towards Reactive Programming for Object-oriented Applications”: http://www.guidosalvaneschi.com/attachments/papers/2014_Towards-Reactive-Programming-for-Object-Oriented-Applications_pdf.pdf http://www.guidosalvaneschi.com/attachments/papers/2014_Towa...

CmonDev 12y ago

"Javascript is the most familiar language out there at the moment" Will people ever stop using this reasoning? Why not pick the best/better language instead?

jrajav 12y ago
Because the goal here is not to write the most efficient and most maintainable code, but to demonstrate a new concept. Familiarity and availability are more relevant in this case than "best language," however you'd measure that.
- derefr 12y ago
  Hmm. Java might be known by more, if just from the fact that those who take an introductory CS course as an elective in another major will get their lessons in it. But, as a lingua franca, it sucks even worse. Mind that term, actually: while French itself was just an average European language, it was handy, for political reasons, for diplomats of all stripes to pick up—and somewhat easy, presuming you had studied texts in Latin. JS is much the same: a lot of us might not prefer it when writing our own code, but we can all certainly read it, given its ALGOL derivation, and it's certainly more pithy than, say, C, for communicating the kind of concepts we need to communicate (like FRP.)
  - Terr_ 12y ago
    > But, as a lingua franca, it sucks even worse. Mind that term, actually: while French itself [...] Mind that term even more, because despite the similar "fr--" sound, it does not actually denote the French language. "Lingua franca" is actually an Italian term for "Frankish language", during a time (post-middle-ages) when "Franks" often referred to Western Europe in general. While French is an example of a language which fit the definition for a period of time, it is not the source of its name.
collyw 12y ago
Agreed.
12y ago

shadytrees 12y ago

We use ReactiveCocoa [0] extensively at work and can't recommend it highly enough [1]. (Although admittedly KVO makes Cocoa almost the ideal platform for reactive programming.) [0]: https://github.com/ReactiveCocoa/ReactiveCocoa https://github.com/ReactiveCocoa/ReactiveCocoa [1]: http://ianthehenry.com/2014/5/4/kvo-101/ http://ianthehenry.com/2014/5/4/kvo-101/

nemanja 12y ago

I also found Martin Odersky's Principles of Reactive Programming Coursera class [1] very helpful. [1] https://class.coursera.org/reactive-001 https://class.coursera.org/reactive-001

X4 12y ago
I and a friend attended to the class and read several papers, but all you learn are concepts, tools, paradigms and implementations. There is no "formula" for creating FRP, it's very generic although highly specific on monads, (applicative) functors, monoids, etc. So definitively worth a shot, if you want to learn everything around FRP.

alipang 12y ago

Here's an introduction to Bacon.js, implementing a game with eventstreams, if anyone is interested in more. http://philipnilsson.github.io/badness/ http://philipnilsson.github.io/badness/

newgame 12y ago

If you're interested in FRP in terms of GUI programming, as described in the linked article, you should definitely checkout ReactFX [0], an FRP library for JavaFX, and also the author Tomas Mikula's blog [1] that contains very convincing examples of FRP's usefulness for real UI tasks [2]. [0]: https://github.com/TomasMikula/ReactFX https://github.com/TomasMikula/ReactFX [1]: http://tomasmikula.github.io/blog/ http://tomasmikula.github.io/blog/ [2]: http://tomasmikula.github.io/blog/2014/04/25/combining-reactfx-and-asynchronous-processing.html http://tomasmikula.github.io/blog/2014/04/25/combining-react... If you are confused by the term FRP and its different interpretations, I tried to summarize them in a stackoverflow answer: http://stackoverflow.com/questions/22795062/is-it-possible-to-translate-the-mario-example-from-elm-to-either-pure-javafx-or/23909098#23909098 http://stackoverflow.com/questions/22795062/is-it-possible-t...

wolfwyrd 12y ago

Lee Campbell's book/site is a good place to start - http://introtorx.com/ http://introtorx.com/

platz 12y ago

Some additional overview of different reactive approaches: http://www.slideshare.net/deanwampler/reactive-design-languages-and-paradigms http://www.slideshare.net/deanwampler/reactive-design-langua... https://www.youtube.com/watch?v=4L3cYhfSUZs https://www.youtube.com/watch?v=4L3cYhfSUZs * responsive (somewhat hand-wavy - basically, don't block on IO) * scalable (hard to be scalable - many different approaches) * resilient (hard to be resilient - erlang is king here) * event-driven (it's hard to not be event-driven these days)

mattpodwysocki 12y ago
The Reactive Extensions covers all of those particular topics quite well, in terms of responsive to failure, responsive to events, responsive to load etc. We cover that a bit in our repository with the Reactive Manifesto: https://github.com/Reactive-Extensions/RxJS https://github.com/Reactive-Extensions/RxJS And I've even covered it at StrangeLoop 2013: video: http://www.infoq.com/presentations/rx-event-processing http://www.infoq.com/presentations/rx-event-processing slides: https://github.com/Reactive-Extensions/StrangeLoop2013 https://github.com/Reactive-Extensions/StrangeLoop2013 As well as FutureJS: video: https://www.youtube.com/watch?v=zlERo_JMGCw https://www.youtube.com/watch?v=zlERo_JMGCw slides: https://github.com/Reactive-Extensions/FutureJS https://github.com/Reactive-Extensions/FutureJS

Paradigma11 12y ago

Names can change over time but here is how i recall it: FRP is a development based on the work of conal elliott: http://conal.net/ http://conal.net/ It's main characteristic is that there is a continuous (pull)aspect. Since many interesting domains are not predominantly continuous he and many others had to add a discrete event based component. Rx is a stream based technology (push). Basically it is a dataflow library with modern functional programming syntactic elements. It does not have a continuous aspect and as such it is not FRP. By treating Rx as something new we are depriving our self of the dataflow and structured programming knowledge.

swanson 12y ago

I've struggled to grok FRP in the past - I hear lots of smart people trumpeting it, but I haven't been able to wrap my head around it. This tutorial was great and I was following along right until it got to the part about modeling the suggestions as streams (https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#modelling-the-3-suggestions-with-streams https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#modellin...). That was where everything went haywire for me - my brain doesn't want to think about those UI elements as streams and I instantly tune out and think "this doesn't make sense". I'm curious if anyone else also got stuck at that same part, as well as if anyone has suggestions/ideas for breaking past this mental barrier? Is there a different way of solving the same problem (that might make more sense to me)?

staltz 12y ago
Hi, can you make that question on the gist so that the discussion persists there? I'd be glad to try to fill in the missing mental bits there.
- swanson 12y ago
  Sure thing :)
skybrian 12y ago
You can think of an animation as a stream of frames; this is how video is implemented. It especially makes sense for video games that typically have a game loop that renders the screen at 30 or 60 frames per second. Similarly, a UI element can be thought of a a stream of snapshots. Each time you render the UI element, you're creating another frame. In Elm, an entire UI is a stream of frames. (The type is Signal Element.) When you put Elements together into a tree, you're just constructing a single frame of an animation. Unfortunately, a UI in Elm is not composable in the same way as a traditional UI. The model, appearance, and behavior of a UI element are handled by different parts of the program. This is sometimes good (model and appearance are cleanly separated) but it's unclear whether we can build large applications this way. It's one of the reasons why Elm is still an experimental language.

TacticalCoder 12y ago

Great article but there's something I'd like to understand: the article talks about FRP yet writes "(Functional) Reactive Programming" with "functional" between parentheses, why? Is the 'F' in FRP the same 'F' as when people say that, for example, Haskell and Clojure are FP languages? Does FRP use the notion of "functions" which are closer to the mathematical definition of a function? For example does FRP try to avoid state and mutable data as much as possible and do the same inputs always lead to the same output? Or is it called "functional" simply because it allows to use things like map/reduce/filter? If it is "really" functional, I take it it's quite deterministic: can you then take all these streams of events and "replay" them at will, always ending up in the same intermediary state and, eventually, in the same final "state"? If that's the case, then it's the next thing on my "to learn" list :)

staltz 12y ago
> There's something I'd like to understand: the article talks about FRP yet writes "(Functional) Reactive Programming" with "functional" between parentheses, why? This comment https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#comment-1255003 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#comment-... and this discussion https://twitter.com/ReactiveX/status/483625917491970048 https://twitter.com/ReactiveX/status/483625917491970048 > If it is "really" functional, I take it it's quite deterministic: can you then take all these streams of events and "replay" them at will, always ending up in the same intermediary state and, eventually, in the same final "state"? Yes. See this http://debug.elm-lang.org/ http://debug.elm-lang.org/

canterburry 12y ago

How is this different from complex event processing (CEP)? High frequency trading has been using this from day 1. The real trick is working with historical events and fetch them from disk, otherwise your reasoning time window is restricted to whatever fits in RAM.

mattpodwysocki 12y ago
Using Rx, you can certainly do CEP as we have buffer and window operators, and the ability to so groupBy and other complex operators. For example we have one that analyzes stock streams https://github.com/Reactive-Extensions/NDC-Oslo-2014/blob/master/demos/WinJS/client/pages/stocks/stocks.js https://github.com/Reactive-Extensions/NDC-Oslo-2014/blob/ma...
- canterburry 12y ago
  So, are you saying Rx is the superset and CEP is a subset of Rx functionality? What can you do in Rx that you can't do in CEP?
  - mattpodwysocki 12y ago
    I would certainly say that Rx has a superset of the operators in standard CEP which largely deals with buffers and windows, yes. In addition, we have time-based join and group join behavior, join calculus eg: Rx.Observable.when( stream1.and(stream2).then(...), stream3.and(stream4).then(...) );

eridius 12y ago

I thought this was a decent tutorial, but I'm a bit annoyed at the double-click bit. Yeah sure, you can implement some form of double-clicks in 4 lines of code, but it behaves badly. And since the tutorial glossed over it, I have no idea if this is just because the author doesn't realize they implemented a really bad click system, or because it takes a lot more than 4 lines of code to do it right and the author didn't like that so chose to ignore it. Notably, the single-click stream has a built-in 250ms delay before the click is fired. That's bad. Similarly, the double-click has a built-in 250ms delay even if the user clicks twice within 100ms. In fact, it's not just a 250ms delay from the first click; it's a 250ms delay from the last click before it finally emits the event. That's a completely unusable way of doing clicks. If that's how you do clicks in FRP, then that's a serious issue with FRP. I have to assume there's a better way, and I'd really like to see it. The correct behavior is to emit a click event immediately upon a click, but to remember recent history and associate a click count with the event based on whether there are recent clicks. So if I click 7 times in a row at sufficient speed, I should get a click event for every single one, getting 1x through 6x clicks before finally getting the 7x click on the last one.

staltz 12y ago
Sure, you can do that. If it's not how you want it to be, just tweak it. http://jsfiddle.net/staltz/U2j4D/8/ http://jsfiddle.net/staltz/U2j4D/8/
- eridius 12y ago
  Thank you, that behaves a lot better. It seems a bit odd that the multiClickStream emits a `0` 200ms after the last click, but I guess you can add the filter to the multiClickStream directly and let the button clear its own text a different way. http://jsfiddle.net/U2j4D/17/ http://jsfiddle.net/U2j4D/17/ So more than 4 lines of code, but I'm glad to see it's quite doable.
- Groxx 12y ago
  Interesting implementation - I'm just starting to poke into reactive, things like this help me think differently :) That said, this is not the same thing as a double-click handler. This is a single click plus a double click when you click twice. Typically when you do double-click handlers you delay single-click until it's a confirmed not-double-click. I think I have an idea of how to make that work here, but do you have a preferred approach?

X4 12y ago

There is one thing that really bothers me, I've not found a single a mathematical formula that defines FRP. The closest thing I've found was the "Denotational Semantics" showing the logic behind, which is quite lenghty and leaves a lot of room for variations. I hate descriptions full of buzzwords that, when you look at it closely have really nothing to do with FRP, but are mere tools that help realizing it. Is there someone who can explain us scholars how FRP can be noted down formaly? Even a link to a page of a paper that shows the formula would be enormously useful. I'll put all the good papers that I've found in the footnoes. -------- 　The following are a few of the good papers on FRP (ordered by subj. quality). I've read the Elm paper, but it's vague despite having a lot of maths in it. What it really decribes is not FRP, but Elm (also it's not exactly FRP). 　[1] https://blogs.janestreet.com/breaking-down-frp/ https://blogs.janestreet.com/breaking-down-frp/ 　[2] Higher-Order Functional Reactive Programming without Spacetime Leaks - https://www.mpi-sws.org/~neelk/simple-frp.pdf https://www.mpi-sws.org/~neelk/simple-frp.pdf 　[3] An Axiomatic Semantics for Functional Reactive Programming - http://www.wpi.edu/Pubs/ETD/Available/etd-042908-133033/unrestricted/cking.pdf http://www.wpi.edu/Pubs/ETD/Available/etd-042908-133033/unre... 　[4] Push-pull functional reactive programming - http://conal.net/papers/push-pull-frp/ http://conal.net/papers/push-pull-frp/ 　[5] Categorical Semantics for Functional Reactive Programming with Temporal Recursion and Corecursion - http://www.cs.bham.ac.uk/~pbl/msfp2014/catsemfrp.pdf http://www.cs.bham.ac.uk/~pbl/msfp2014/catsemfrp.pdf 　[6] Completeness of Conversion between Reactive Programs for Ultrametric Models - http://www.cs.le.ac.uk/people/fdv1/fdv1/Distribution/SeveriDeVriesTLCA2013.pdf http://www.cs.le.ac.uk/people/fdv1/fdv1/Distribution/SeveriD... 　[7] Fair Reactive Programming - http://www.cs.mcgill.ca/~acave1/papers/fair-reactive.pdf http://www.cs.mcgill.ca/~acave1/papers/fair-reactive.pdf 　[8] A Survey on Reactive Programming - http://soft.vub.ac.be/Publications/2012/vub-soft-tr-12-13.pdf http://soft.vub.ac.be/Publications/2012/vub-soft-tr-12-13.pd... 　[9] Signals, Not Generators! - http://www.ioc.ee/~wolfgang/research/tfp-2009-slides.pdf http://www.ioc.ee/~wolfgang/research/tfp-2009-slides.pdf 　[10] http://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language#5878525 http://stackoverflow.com/questions/5875929/specification-for... 　[11] http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming/1030631#1030631 http://stackoverflow.com/questions/1028250/what-is-functiona... The bad thing about all those papers is that a) you need to know Category Theory, b) Temporal Logic, c) Denotational Semantics d) (and optionally Henkin and Ultrametric Models) Unfortunately I'm not yet that smart :( hope someone can bring clarity into FRP Sorry for the ugly footnote, that's the best I got using HN's formatting capability. Update: I used unicode spaces, that fixed it.

scotty79 12y ago

If you want to learn streams the hard way try to implement any non trivial build process with gulp.js Just a warrning. Node.js had 3 versions of streams so far and some packages that implement stream functionality don't all work properly with latest version. Also two types bytestream and object stream.

mattpodwysocki 12y ago
Node.js streams are largely unicast, instead RxJS and related libraries can be multicast. RxJS, on the other hand has been fairly stable for quite some time now and the APIs largely haven't changed from when we first released in 2010.

heydenberk 12y ago

It looks to me like Bacon.js is the community favorite and RxJS is the corporate framework when it comes to JavaScript libraries for FRP. I'm thinking about introducing an FRP library into the frontend stack where I work — does anyone have any experience with using either of these libraries (or another) for corporate work? What did you use and how did your coworkers deal with it?

mattpodwysocki 12y ago
As the primary author of RxJS, I take exception to that characterization. Anyways, you should look at the performance differences between RxJS and Bacon.js. They are quite significant! https://github.com/pozadi/kefir/blob/master/test/perf/memory-results.txt https://github.com/pozadi/kefir/blob/master/test/perf/memory...
- novaleaf 12y ago
  Hi Matt, fyi the codeplex page doesn't mention what appears to be the primary website: http://reactive-extensions.github.io/RxJS/ http://reactive-extensions.github.io/RxJS/ so you might want to get a link added....
- heydenberk 12y ago
  I should be clear that I'm only referring to the superficial characteristics about the frameworks. Nothing about the API itself seems very corporate. Thanks for the pointer to the performance characteristics. I'm interested in differentiating factors.

steveklabnik 12y ago

I wrote a little FRP library in Ruby: https://github.com/steveklabnik/frappuccino https://github.com/steveklabnik/frappuccino

mattpodwysocki 12y ago
steveklabnik, still working on the Ruby port of Rx. It will get there but needs more community support.

latentflip 12y ago

To add another resource to the list, I gave an introductory talk to bacon.js and FRP last year which has similar diagrams to these which I animated with d3 if anyone'a interested: http://vimeo.com/m/68987289 http://vimeo.com/m/68987289

davexunit 12y ago

I am writing a game engine in Scheme that uses FRP. My implementation may not be robust since I'm the only user, but perhaps seeing what it can do will help someone. My implementation was heavily inspired by Elm. Blog post with screencast to demonstrate: http://dthompson.us/functional-reactive-programming-in-scheme-with-guile-2d.html http://dthompson.us/functional-reactive-programming-in-schem... Implementation details: https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2431e4d920f0b678ba:sly/signal.scm https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2... 2048 clone written in a reactive style: https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2431e4d920f0b678ba:examples/2048/2048 https://gitorious.org/sly/sly/source/8cf0096791821c7711c9dc2... Reading the explanation from the Elm folks is what made things click for me: http://elm-lang.org/learn/What-is-FRP.elm http://elm-lang.org/learn/What-is-FRP.elm Edit: Also, SICP has 2 sections that describe systems that are reminiscent of reactive programming systems. A Simulator for Digital Circuits: https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4 https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.htm... Propagation of Constraints: https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.5 https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.htm...

seanmcdirmid 12y ago
Why not look at Gregory Cooper et. al.'s FrTime? Its the first FRP system I'm aware of for Scheme, and its quite well used in Racket. It is also a predecessor of Flapjax. http://docs.racket-lang.org/frtime/ http://docs.racket-lang.org/frtime/
- davexunit 12y ago
  I've read some of this source, too. Thanks.

mjackson 12y ago

> FRP streams go beyond promises by allowing many returned values. This is pretty nice, and shows how FRP is at least as powerful as Promises. The fact that you can only return a single value from a promise is a feature, not a limitation. In synchronous code, you can only return once from a function. In asynchronous promise code, you can only fulfill the promise once. There's a parallel. If you want to "allow many returned values" you can just use a callback. You hardly need a "stream" for that.

AgentME 12y ago
A stream can be thought of like a function in a lazy language returning an array of results which aren't necessarily calculated (or available) all at once. >If you want to "allow many returned values" you can just use a callback. You hardly need a "stream" for that. Callbacks are hard to compose, may not have standard error conventions, and you can't have multiple listeners subscribe to the same thing after the fact. (Those are the same things that promises solve for async functions with a single result.) Additionally, you can stop listening to a stream and the source can know to close itself once it has no more listeners.
klibertp 12y ago
> In synchronous code, you can only return once from a function. Erm, have you heard a term "continuation" or "call/cc" ("call-with-curent-continuation")? Or "delimited continuations"? Or maybe even "Cont monad"? You should read on them, if you haven't - they are one of the most fundamental and fun concepts I encountered. But even without those, what you wrote here is false in the presence of generators (which are coming to JS any day now!). I'd say that returning more than once from function is actually a pretty basic technique which is widely used to implement quite a wide array of different things.
- dllthomas 12y ago
  Or, over in C land, setjmp.

moondowner 12y ago

RxJava's wiki is also pretty good: https://github.com/Netflix/RxJava/wiki https://github.com/Netflix/RxJava/wiki

prawks 12y ago

With seemingly more emphasis being placed on complex pub-sub architectures, has there been any equivalent development of tooling to assist in visualizing/grokking an existing pub-sub application? In my experience at least, pub-sub architecture can be difficult to follow without good tooling (trying to keep all of these coexisting streams in your head when making changes, as asynchronous code is difficult to write a test suite for that could catch mistakes). This is somewhat just the nature of asynchronous programming, but there has been more and more emphasis on that as well with the popularity of highly responsive GUI applications and more computing capacity for background tasks. Aside from using Visual Studio-esque "find references" to navigate to all of the locations in a codebase where a particular event stream is subscribed to, I've yet to come across much.

moondowner 12y ago

For those searching for Rx examples, I found these: https://github.com/fdecampredon/react-rxjs-todomvc https://github.com/fdecampredon/react-rxjs-todomvc (TodoMVC implementation built on top of React + RxJS) https://github.com/eliseumds/react-autocomplete https://github.com/eliseumds/react-autocomplete (React + RxJS Autocomplete)

mattpodwysocki 12y ago
Yep, there are plenty of examples to be found such as those listed here: https://github.com/Reactive-Extensions/NDC-Oslo-2014 https://github.com/Reactive-Extensions/NDC-Oslo-2014 In addition, we ship a good number of samples within our RxJS repository: https://github.com/Reactive-Extensions/RxJS/tree/master/examples https://github.com/Reactive-Extensions/RxJS/tree/master/exam...
- moondowner 12y ago
  Cool!