7 ms·

Functional Reactive Programming

79 points by niutech 8y ago

danharaj 8y ago
None of this is functional reactive programming as originally formulated by Conal Elliott and Paul Hudak, which in particular emphasized the need to model reactive programs as the algebraic composition of simple abstract units, events and behaviors. If you have to set up a listener for an event, you aren't doing FRP, you're just doing Reactive Programming.
- paperwork 8y ago
  Unfortunately a very common mixup. Here is Erik Meijer (aka headinthebox), the main guy behind Rx, talking about the difference[1]: Let's keep "FRP" for what it really stands for in honor of it's inventor (http://conal.net/talks/ http://conal.net/talks/). Rx is not FRP and was explicitly designed as a discrete collection API on purpose (as opposed to continuous time varying values). ... [1] https://github.com/ReactiveX/reactivex.github.io/issues/130 https://github.com/ReactiveX/reactivex.github.io/issues/130
  - mpweiher 8y ago
    Of course Conal no longer likes the name Functional Reactive Programming for what he did. And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming. Sigh.
    - jcelerier 8y ago
      > And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming. well, dataflow programming has always been central to reactive programming, isn't it ? that's what all reactive languages, Esterel, Lustre, etc. were about.
      - mpweiher 8y ago
        Yes, that's what I am saying, or rather: it's not "central to it", it is the thing itself. "Reactive" is really just a re-branding of (synchronous) dataflow programming, and a fairly bad one at that because it just jumbles up and confuses so many things. "Reactive" is/was really a type of system: one where you have continuous interaction with the outside world and the world generally cannot wait (similar but not identical to real-time). Contrasting with "transformational", where you just get some inputs turn them into outputs and are done, and "interactive", where you interact with the outside world but the world can wait. It turned out that the synchronous dataflow languages (like Esterel, which is imperative, and Lustre, which is functional) had some fairly nice properties when it came to building reactive systems. As far as I know, Esterel is used for Airbus avionics...so the outside world really, really cannot wait :-) How people somehow managed to mix up the style of system with the technology and then somehow also put in a claim that "functional" was an essential part of it is a little beyond me.
      - junke 8y ago
        > ... were about. are about.
- jonahx 8y ago
  Nice talk by Conal Elliott on the original formulation: https://www.youtube.com/watch?v=j3Q32brCUAI https://www.youtube.com/watch?v=j3Q32brCUAI
- jarcane 8y ago
  This has been very frustrating to me because it feels like many reactive frameworks for OOP languages are actively muddying the waters. I've had stuff like ReactiveX recommended to me as "FRP" and it's nothing like the form, and just wastes my time. If actual FRP for web wasn't doing so relatively well, I would begin to fear that FRP is heading the same way OOP did after Smalltalk, a shadow of the actual thing pushed as a buzzword to sell to marketing managers with no clue or concern about the actual tech. And god help me, I do not want to see what the C++ of FRP looks like ...
  - jcelerier 8y ago
    > And god help me, I do not want to see what the C++ of FRP looks like ... plenty of reactive libs in there. The original one was Qt with the signal system. More recent research in this domain is for instance RaftLib : https://github.com/RaftLib/RaftLib/blob/master/examples/general/sum/sumapp.cpp https://github.com/RaftLib/RaftLib/blob/master/examples/gene...
    - jarcane 8y ago
      Not quite the analogy I was alluding to. Ie. not so much "FRP in C++" as "C++ : OOP :: ___ : FRP." Though I grant you that C++ could just as easily wind up filling both blanks.
  - andrekandre 8y ago
    judging from where i work, that has already happened to a large degree, and i would guess elsewhere too... as alan kay would say "its all a pop culture" edit: spelling mistake
- Vinnl 8y ago
  This same discussion comes up every time FRP is mentioned, because most articles that say they are about FRP are about Reactive Programming using Functional methods. You can keep bring it up every time you see such a post, but maybe it's better for your own sanity to just realise that ship has sailed: when people write about FRP, they write about this. As Elliott himself suggested [0], it might be a good idea to use the term DCTP when talking about the concept you're talking about. Yes, it might feel wrong because his FRP was "first", but at least it's clear. > To reduce confusion, I would like to see the term “functional reactive programming” replaced by the more accurate & descriptive “denotative, continuous-time programming” (DCTP) [0] http://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language/5878525#5878525 http://stackoverflow.com/questions/5875929/specification-for...
  - danharaj 8y ago
    This same discussion comes up every time FRP is mentioned, because most articles that say they are about FRP are about Reactive Programming using Functional methods. You can keep bring it up every time you see such a post, but maybe it's better for your own sanity to just realise that ship has sailed: when people write about FRP, they write about this. My job is to write actual FRP so it's no sweat for me to vigorously complain every time that people are stealing "my" term :p While Conal may have distanced himself from FRP, in the Haskell FRP community that's what we still call it.
    - Vinnl 8y ago
      Haha, well, if it's no effort for you to keep it up, then by all means, keep it up :) Just don't expect it to actually change :P
  - jjtheblunt 8y ago
    DCTP ?
mchahn 8y ago
Can someone explain the synergy of using reactive with functional? Reactive is great and functional is great but I don't see what they have to do with each other.
- pcstl 8y ago
  It's easier to reason about highly asynchronous code if all you can do is transform and compose streams, and all side-effecting work happens at the "ends of the pipe", so to say. Arbitrary side-effects coupled with asynchronicity are a recipe for Heisenbugs. Additionally, if you add in the constraint that you can't change signal routing at runtime and you only use pure functions on stream, you can actually debug by moving streams to any point in their history and figuring out what the system is doing with them. That's a very common debugging technique in the Elm programming language, for instance, as shown here: https://www.youtube.com/watch?v=RUeLd7T7Xi4 https://www.youtube.com/watch?v=RUeLd7T7Xi4.
  - seanmcdirmid 8y ago
    Is that really common among Elm programmers? As far as I can tell, it was a nice one off demo but it hasn't been advanced as Elm has.
    - hellofunk 8y ago
      I met an Elm dev once, who even after two years, had not used it or even knew how.
    - pcstl 8y ago
      It's been sort of left behind as Elm has de-emphasized FRP. I used it a lot, though.
    - fpoling 8y ago
      From my small experience with following Elm tutorials and implementing simple apps is that such debugging is not necessary. Elm strongly encourages to use a serializable state with no things like long-lived lambdas or closures capturing arbitrary stack frames. In turns it makes reasoning about the code very easy. In my cases just by observing the bug for the first time I could almost immediately find the code triggering the misfeature. This was absolutely not the case with pages with relatively small JS that I dealt occasionally in past.
baron816 8y ago
Does anyone know if React got its name from React Programming?
- baron816 8y ago
  Why was this downvoted? React essentially uses observables, right? Child components don’t directly listen to changes in the state objects of their parents. Instead, parents know how to update their children when setState is called. Thus, the inversion of dependencies decouples objects in React in the same way observers are decoupled from their subjects in RxJS. Redux has a dependency on RXJS for a reason.
  - baron816 8y ago
    I’ll just ask Dan.
  - reaktivo 8y ago
    Redux doesn’t have a dependency on RxJS. It does expose and observable interface though
- Vinnl 8y ago
  It does not, I think: > There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”. (from [0]) You could look at a React+Redux application as a somewhat limited reactive architecture though: [1] (from [2]). [0] https://reactjs.org/docs/design-principles.html https://reactjs.org/docs/design-principles.html [1] https://vincenttunru.com/assets/img/Javascript-reactive-programming/react_architecture.png https://vincenttunru.com/assets/img/Javascript-reactive-prog... [2] https://vincenttunru.com/Javascript-reactive-programming/ https://vincenttunru.com/Javascript-reactive-programming/
sebringj 8y ago
In practice, I've used socket.io and redis to glue dbs and apis and queues and schedulers and clients together and the clients listen to sockets for data payloads to modify the views. View interaction sends event payloads to modify the various systems which kick off further data payloads. That is the entire concept. No article was necessary in the making of this post.
a_imho 8y ago
To achieve such effect as presented above you need to use Server-Sent Events (SSE) I was wondering whether it is possible to achieve the same effect without client side JS, perhaps with HTTP2 push?

79 points by niutech 8y ago

None of this is functional reactive programming as originally formulated by Conal Elliott and Paul Hudak, which in particular emphasized the need to model reactive programs as the algebraic composition of simple abstract units, events and behaviors. If you have to set up a listener for an event, you aren't doing FRP, you're just doing Reactive Programming.

paperwork 8y ago
Unfortunately a very common mixup. Here is Erik Meijer (aka headinthebox), the main guy behind Rx, talking about the difference[1]: Let's keep "FRP" for what it really stands for in honor of it's inventor (http://conal.net/talks/ http://conal.net/talks/). Rx is not FRP and was explicitly designed as a discrete collection API on purpose (as opposed to continuous time varying values). ... [1] https://github.com/ReactiveX/reactivex.github.io/issues/130 https://github.com/ReactiveX/reactivex.github.io/issues/130
- mpweiher 8y ago
  Of course Conal no longer likes the name Functional Reactive Programming for what he did. And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming. Sigh.
  - jcelerier 8y ago
    > And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming. well, dataflow programming has always been central to reactive programming, isn't it ? that's what all reactive languages, Esterel, Lustre, etc. were about.
    - mpweiher 8y ago
      Yes, that's what I am saying, or rather: it's not "central to it", it is the thing itself. "Reactive" is really just a re-branding of (synchronous) dataflow programming, and a fairly bad one at that because it just jumbles up and confuses so many things. "Reactive" is/was really a type of system: one where you have continuous interaction with the outside world and the world generally cannot wait (similar but not identical to real-time). Contrasting with "transformational", where you just get some inputs turn them into outputs and are done, and "interactive", where you interact with the outside world but the world can wait. It turned out that the synchronous dataflow languages (like Esterel, which is imperative, and Lustre, which is functional) had some fairly nice properties when it came to building reactive systems. As far as I know, Esterel is used for Airbus avionics...so the outside world really, really cannot wait :-) How people somehow managed to mix up the style of system with the technology and then somehow also put in a claim that "functional" was an essential part of it is a little beyond me.
    - junke 8y ago
      > ... were about. are about.
jonahx 8y ago
Nice talk by Conal Elliott on the original formulation: https://www.youtube.com/watch?v=j3Q32brCUAI https://www.youtube.com/watch?v=j3Q32brCUAI
jarcane 8y ago
This has been very frustrating to me because it feels like many reactive frameworks for OOP languages are actively muddying the waters. I've had stuff like ReactiveX recommended to me as "FRP" and it's nothing like the form, and just wastes my time. If actual FRP for web wasn't doing so relatively well, I would begin to fear that FRP is heading the same way OOP did after Smalltalk, a shadow of the actual thing pushed as a buzzword to sell to marketing managers with no clue or concern about the actual tech. And god help me, I do not want to see what the C++ of FRP looks like ...
- jcelerier 8y ago
  > And god help me, I do not want to see what the C++ of FRP looks like ... plenty of reactive libs in there. The original one was Qt with the signal system. More recent research in this domain is for instance RaftLib : https://github.com/RaftLib/RaftLib/blob/master/examples/general/sum/sumapp.cpp https://github.com/RaftLib/RaftLib/blob/master/examples/gene...
  - jarcane 8y ago
    Not quite the analogy I was alluding to. Ie. not so much "FRP in C++" as "C++ : OOP :: ___ : FRP." Though I grant you that C++ could just as easily wind up filling both blanks.
- andrekandre 8y ago
  judging from where i work, that has already happened to a large degree, and i would guess elsewhere too... as alan kay would say "its all a pop culture" edit: spelling mistake
Vinnl 8y ago
This same discussion comes up every time FRP is mentioned, because most articles that say they are about FRP are about Reactive Programming using Functional methods. You can keep bring it up every time you see such a post, but maybe it's better for your own sanity to just realise that ship has sailed: when people write about FRP, they write about this. As Elliott himself suggested [0], it might be a good idea to use the term DCTP when talking about the concept you're talking about. Yes, it might feel wrong because his FRP was "first", but at least it's clear. > To reduce confusion, I would like to see the term “functional reactive programming” replaced by the more accurate & descriptive “denotative, continuous-time programming” (DCTP) [0] http://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language/5878525#5878525 http://stackoverflow.com/questions/5875929/specification-for...
- danharaj 8y ago
  This same discussion comes up every time FRP is mentioned, because most articles that say they are about FRP are about Reactive Programming using Functional methods. You can keep bring it up every time you see such a post, but maybe it's better for your own sanity to just realise that ship has sailed: when people write about FRP, they write about this. My job is to write actual FRP so it's no sweat for me to vigorously complain every time that people are stealing "my" term :p While Conal may have distanced himself from FRP, in the Haskell FRP community that's what we still call it.
  - Vinnl 8y ago
    Haha, well, if it's no effort for you to keep it up, then by all means, keep it up :) Just don't expect it to actually change :P
- jjtheblunt 8y ago
  DCTP ?

mchahn 8y ago

Can someone explain the synergy of using reactive with functional? Reactive is great and functional is great but I don't see what they have to do with each other.

pcstl 8y ago
It's easier to reason about highly asynchronous code if all you can do is transform and compose streams, and all side-effecting work happens at the "ends of the pipe", so to say. Arbitrary side-effects coupled with asynchronicity are a recipe for Heisenbugs. Additionally, if you add in the constraint that you can't change signal routing at runtime and you only use pure functions on stream, you can actually debug by moving streams to any point in their history and figuring out what the system is doing with them. That's a very common debugging technique in the Elm programming language, for instance, as shown here: https://www.youtube.com/watch?v=RUeLd7T7Xi4 https://www.youtube.com/watch?v=RUeLd7T7Xi4.
- seanmcdirmid 8y ago
  Is that really common among Elm programmers? As far as I can tell, it was a nice one off demo but it hasn't been advanced as Elm has.
  - hellofunk 8y ago
    I met an Elm dev once, who even after two years, had not used it or even knew how.
  - pcstl 8y ago
    It's been sort of left behind as Elm has de-emphasized FRP. I used it a lot, though.
  - fpoling 8y ago
    From my small experience with following Elm tutorials and implementing simple apps is that such debugging is not necessary. Elm strongly encourages to use a serializable state with no things like long-lived lambdas or closures capturing arbitrary stack frames. In turns it makes reasoning about the code very easy. In my cases just by observing the bug for the first time I could almost immediately find the code triggering the misfeature. This was absolutely not the case with pages with relatively small JS that I dealt occasionally in past.

baron816 8y ago

Does anyone know if React got its name from React Programming?

baron816 8y ago
Why was this downvoted? React essentially uses observables, right? Child components don’t directly listen to changes in the state objects of their parents. Instead, parents know how to update their children when setState is called. Thus, the inversion of dependencies decouples objects in React in the same way observers are decoupled from their subjects in RxJS. Redux has a dependency on RXJS for a reason.
- baron816 8y ago
  I’ll just ask Dan.
- reaktivo 8y ago
  Redux doesn’t have a dependency on RxJS. It does expose and observable interface though
Vinnl 8y ago
It does not, I think: > There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”. (from [0]) You could look at a React+Redux application as a somewhat limited reactive architecture though: [1] (from [2]). [0] https://reactjs.org/docs/design-principles.html https://reactjs.org/docs/design-principles.html [1] https://vincenttunru.com/assets/img/Javascript-reactive-programming/react_architecture.png https://vincenttunru.com/assets/img/Javascript-reactive-prog... [2] https://vincenttunru.com/Javascript-reactive-programming/ https://vincenttunru.com/Javascript-reactive-programming/

sebringj 8y ago

In practice, I've used socket.io and redis to glue dbs and apis and queues and schedulers and clients together and the clients listen to sockets for data payloads to modify the views. View interaction sends event payloads to modify the various systems which kick off further data payloads. That is the entire concept. No article was necessary in the making of this post.

a_imho 8y ago

To achieve such effect as presented above you need to use Server-Sent Events (SSE) I was wondering whether it is possible to achieve the same effect without client side JS, perhaps with HTTP2 push?