5 ms·

It looks like we are going to keep reinventing dataflow constraints[1] over and over again, always with slightly different terminology (Rx, FRP, signals, ...)

It looks like we are going to keep reinventing dataflow constraints[1] over and over again, always with slightly different terminology (Rx, FRP, signals, ...) So it (a) appears to be a very useful or at least attractive concept, and (b) somehow difficult to fit into current programming languages/practice in a clean way. [1] https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an... (HN: https://news.ycombinator.com/item?id=7404149 https://news.ycombinator.com/item?id=7404149 )

klabb3 3y ago
I feel like reactive programming is approaching ripeness for a mainstream programming language or cross-stack paradigm within the next few years. React, Svelte, Redux etc in the frontend world has certainly paved the way on the mainstream side, albeit in a simplified environment (singlethreaded, does not cross the network boundary and can simply share memory cheaply). I wonder if a refined version of this with will prevail, or something else like Rx? What are the primitive operations in such a model? Streams, futures, “watch” APIs?
- dgellow 3y ago
  ReactiveUI is based on Rx and is very popular in the .Net world: https://www.reactiveui.net/ https://www.reactiveui.net/.
- bheadmaster 3y ago
  What's the difference between reactive and functional programming? Both seem to focus on expressing relationships between objects and having compiler/runtime infer the computation, instead of explicitly specifying the computation.
  - ed_blackburn 3y ago
    Perhaps if you framed your question subtly differently and asked yourself what is the difference between Erlang and OTP, the answer maybe easier to discern?
    - bheadmaster 3y ago
      What's the exact difference between Erlang and OTP that would answer my question?
      - ed_blackburn 3y ago
        OTP is the means by which the programming language is able to accomplish tasks such as process to process comms, how to supervise actors etc. It's the enabler for the distributed computing compared to Erlang which is the programming language. They're (obviously) complementary but OTP is the magic that enable one to deliver on the reactive manifesto. Functional programming needs augmenting with mechanisms that provide the distributed computing features, it's not enough on its own.
        bheadmaster 3y ago
        Thanks for the explanation. Where does reactive programming fit in that concept? Is OTP a "reactive" library? If so, why - what exactly makes it "reactive"?
  - ReleaseCandidat 3y ago
    Most of the time the term used is "Functional Reactive Programming". If that answers your question. Although there exists a paper about "Reactive Imperative Programming" (with Dataflow Constraints): https://typeset.io/pdf/reactive-imperative-programming-with-dataflow-constraints-43eczl0oe5.pdf https://typeset.io/pdf/reactive-imperative-programming-with-...
  - dgb23 3y ago
    > Both seem to focus on expressing relationships between objects and having compiler/runtime infer the computation, instead of explicitly specifying the computation. That's true of every declarative approach. Functional, reactive, relational, regex etc. are all to some degree declarative. To answer your question: Functional programming is really more about avoiding mutation at the language surface, while reactive programming is about how mutation propagates through code, so it's an abstraction over specific mutation. This is why they pair nicely together.
- quickthrower2 3y ago
  Elm was positioned to be this. Still technically could be, but adoption isn’t high. Original Elm had signals.
- agumonkey 3y ago
  I'd go even one step further, diffusion/chemical/tissue-level programming. I'm sense the idea of multi agent state morphism becoming a norm in people's mind. (from css to to react to kubernetes).
- idkwhoiam 3y ago
  The native (future) solution for Apple platforms is SwiftUI [1] + Combine [2]. I use it on a side project and for somebody who works with React 9-5 it feels very natural. In short SwiftUI is like React & Combine is like RxJs. [1] - https://developer.apple.com/tutorials/swiftui https://developer.apple.com/tutorials/swiftui [2] - https://developer.apple.com/documentation/combine https://developer.apple.com/documentation/combine
  - ElFitz 3y ago
    While I agree, I’d say I find SwiftUI easier and more intuitive than React. And Combine often much more frustrating than Rx.
awestroke 3y ago
The idea in and of itself is not what is being rediscovered. Nobody is reinventing the wheel. It's whether the implementation is ergonomic and powerful that determines whether it catches on.
- flagrant_taco 3y ago
  Signals have become enough of a buzz word that they may catch on just for the hype, regardless of whether they are particularly powerful or ergonomic.
  - naasking 3y ago
    I feel like signals have been a buzzword for almost 10 years now.
    - flagrant_taco 3y ago
      May just be my memory failing me or the circles I ran in over the years, but I remember the related buzzwords always being observables and streams. I hadn't seen much interest/hype in the actual term "signal" until solidjs used it and push heavily on comparisons with react hooks.
      - naasking 3y ago
        "Signal" has been used in FRP circles for some time [1,2]. The original FRP stuff was events/signals and behaviours. But I agree that JS didn't use this terminology until more recently. S.js is maybe one of the earlier ones, but that was still over 8 years ago. [1] https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=6516&context=theses https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=651... [2] https://github.com/14427/signal https://github.com/14427/signal [3] https://github.com/adamhaile/S/tree/e897ec1212a073bb1fe695e14cae581f80c4464c https://github.com/adamhaile/S/tree/e897ec1212a073bb1fe695e1...
neel_k 3y ago
Surprisingly, FRP doesn't have anything to do with dataflow constraints at all. In FRP, a program is fundamentally a function of type Stream Input → Stream Output. That is, a program transforms a stream of inputs into a stream of outputs. If you think about this a bit more, you realise that any implementable function has to be one whose first k outputs are determined by at most the first k inputs -- i.e., you can't look into the future. That is, these functions have to be causal. The causality constraint implies (with a not-entirely trivial proof) that every causal stream function is equivalent to a state machine (and vice-versa) -- i.e., a current state s, and an update function f : State × Input → State × Output. You get the stream by using the update function to produce a new state and an output in response to each input. (This is an infinite-state Mealy machine for the experts.) Note that there is no dataflow here: it's just an ordinary state machine. As a result, the GUI paradigm that traditional FRP lends itself to the best are immediate mode GUIs. (FRP can be extended to handle asynchronous events, but doing so in a way that has the right performance model is not trivial. Think about how you'd mix immediate and retained mode to get an idea about the issues.) When I first started working on FRP I thought it had to be dataflow -- my first papers on it are actually about signals libraries like the one in the post. However, I learned that basing it on dataflow and/or incremental computation was both unnecessary and expensive. IMO, we should save that for when we really need it, but shouldn't use it by default.
- agumonkey 3y ago
  someone calls conal elliott
- mpweiher 3y ago
  A couple of notes: 1. You seem to be confusing "dataflow constraints" with "dataflow". Though related, they are not the same. 2. Yes, the implementation of Rx-style "FRP" (should have used the scare quotes to indicate I am referring to the common usage, not actual FRP as defined by Conal Elliott) has deviated. And has deviated before. This also happened with Lucid. 3. However, the question is which of the two is the unnecessary bit. As far as I can tell, what people actually want from this is "it should work like a spreadsheet", so dataflow constraints (also known as spreadsheet constraints). This is also how people understand when used practically. And of course dataflow is also where all this Rx stuff came from (see Messerschmitt's synchronous dataflow) 4. Yes, the synchronous dataflow languages Lustre and Esterel apparently can be and routinely are compiled to state machines. In fact, if I understood the papers correctly the synchronous dataflow languages are seen as a convenient way to specify state machines. 5. It would probably help if you added some links to your papers.
giovannibonetti 3y ago
A language/framework that explored well this idea is Elm, which is used in front-end apps. It started with Signals and FRP, then 7 years ago changed course to the Model-View Update architecture [1], today known as The Elm Architecture. It is still a bit niche, but a handful of frameworks in other languages like Rust are following this architecture for GUI apps. [1] https://elm-lang.org/news/farewell-to-frp https://elm-lang.org/news/farewell-to-frp

klabb3 3y ago

I feel like reactive programming is approaching ripeness for a mainstream programming language or cross-stack paradigm within the next few years. React, Svelte, Redux etc in the frontend world has certainly paved the way on the mainstream side, albeit in a simplified environment (singlethreaded, does not cross the network boundary and can simply share memory cheaply). I wonder if a refined version of this with will prevail, or something else like Rx? What are the primitive operations in such a model? Streams, futures, “watch” APIs?

dgellow 3y ago
ReactiveUI is based on Rx and is very popular in the .Net world: https://www.reactiveui.net/ https://www.reactiveui.net/.
bheadmaster 3y ago
What's the difference between reactive and functional programming? Both seem to focus on expressing relationships between objects and having compiler/runtime infer the computation, instead of explicitly specifying the computation.
- ed_blackburn 3y ago
  Perhaps if you framed your question subtly differently and asked yourself what is the difference between Erlang and OTP, the answer maybe easier to discern?
  - bheadmaster 3y ago
    What's the exact difference between Erlang and OTP that would answer my question?
    - ed_blackburn 3y ago
      OTP is the means by which the programming language is able to accomplish tasks such as process to process comms, how to supervise actors etc. It's the enabler for the distributed computing compared to Erlang which is the programming language. They're (obviously) complementary but OTP is the magic that enable one to deliver on the reactive manifesto. Functional programming needs augmenting with mechanisms that provide the distributed computing features, it's not enough on its own.
      - bheadmaster 3y ago
        Thanks for the explanation. Where does reactive programming fit in that concept? Is OTP a "reactive" library? If so, why - what exactly makes it "reactive"?
- ReleaseCandidat 3y ago
  Most of the time the term used is "Functional Reactive Programming". If that answers your question. Although there exists a paper about "Reactive Imperative Programming" (with Dataflow Constraints): https://typeset.io/pdf/reactive-imperative-programming-with-dataflow-constraints-43eczl0oe5.pdf https://typeset.io/pdf/reactive-imperative-programming-with-...
- dgb23 3y ago
  > Both seem to focus on expressing relationships between objects and having compiler/runtime infer the computation, instead of explicitly specifying the computation. That's true of every declarative approach. Functional, reactive, relational, regex etc. are all to some degree declarative. To answer your question: Functional programming is really more about avoiding mutation at the language surface, while reactive programming is about how mutation propagates through code, so it's an abstraction over specific mutation. This is why they pair nicely together.
quickthrower2 3y ago
Elm was positioned to be this. Still technically could be, but adoption isn’t high. Original Elm had signals.
agumonkey 3y ago
I'd go even one step further, diffusion/chemical/tissue-level programming. I'm sense the idea of multi agent state morphism becoming a norm in people's mind. (from css to to react to kubernetes).
idkwhoiam 3y ago
The native (future) solution for Apple platforms is SwiftUI [1] + Combine [2]. I use it on a side project and for somebody who works with React 9-5 it feels very natural. In short SwiftUI is like React & Combine is like RxJs. [1] - https://developer.apple.com/tutorials/swiftui https://developer.apple.com/tutorials/swiftui [2] - https://developer.apple.com/documentation/combine https://developer.apple.com/documentation/combine
- ElFitz 3y ago
  While I agree, I’d say I find SwiftUI easier and more intuitive than React. And Combine often much more frustrating than Rx.

awestroke 3y ago

The idea in and of itself is not what is being rediscovered. Nobody is reinventing the wheel. It's whether the implementation is ergonomic and powerful that determines whether it catches on.

flagrant_taco 3y ago
Signals have become enough of a buzz word that they may catch on just for the hype, regardless of whether they are particularly powerful or ergonomic.
- naasking 3y ago
  I feel like signals have been a buzzword for almost 10 years now.
  - flagrant_taco 3y ago
    May just be my memory failing me or the circles I ran in over the years, but I remember the related buzzwords always being observables and streams. I hadn't seen much interest/hype in the actual term "signal" until solidjs used it and push heavily on comparisons with react hooks.
    - naasking 3y ago
      "Signal" has been used in FRP circles for some time [1,2]. The original FRP stuff was events/signals and behaviours. But I agree that JS didn't use this terminology until more recently. S.js is maybe one of the earlier ones, but that was still over 8 years ago. [1] https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=6516&context=theses https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=651... [2] https://github.com/14427/signal https://github.com/14427/signal [3] https://github.com/adamhaile/S/tree/e897ec1212a073bb1fe695e14cae581f80c4464c https://github.com/adamhaile/S/tree/e897ec1212a073bb1fe695e1...

neel_k 3y ago

Surprisingly, FRP doesn't have anything to do with dataflow constraints at all. In FRP, a program is fundamentally a function of type Stream Input → Stream Output. That is, a program transforms a stream of inputs into a stream of outputs. If you think about this a bit more, you realise that any implementable function has to be one whose first k outputs are determined by at most the first k inputs -- i.e., you can't look into the future. That is, these functions have to be causal. The causality constraint implies (with a not-entirely trivial proof) that every causal stream function is equivalent to a state machine (and vice-versa) -- i.e., a current state s, and an update function f : State × Input → State × Output. You get the stream by using the update function to produce a new state and an output in response to each input. (This is an infinite-state Mealy machine for the experts.) Note that there is no dataflow here: it's just an ordinary state machine. As a result, the GUI paradigm that traditional FRP lends itself to the best are immediate mode GUIs. (FRP can be extended to handle asynchronous events, but doing so in a way that has the right performance model is not trivial. Think about how you'd mix immediate and retained mode to get an idea about the issues.) When I first started working on FRP I thought it had to be dataflow -- my first papers on it are actually about signals libraries like the one in the post. However, I learned that basing it on dataflow and/or incremental computation was both unnecessary and expensive. IMO, we should save that for when we really need it, but shouldn't use it by default.

agumonkey 3y ago
someone calls conal elliott
mpweiher 3y ago
A couple of notes: 1. You seem to be confusing "dataflow constraints" with "dataflow". Though related, they are not the same. 2. Yes, the implementation of Rx-style "FRP" (should have used the scare quotes to indicate I am referring to the common usage, not actual FRP as defined by Conal Elliott) has deviated. And has deviated before. This also happened with Lucid. 3. However, the question is which of the two is the unnecessary bit. As far as I can tell, what people actually want from this is "it should work like a spreadsheet", so dataflow constraints (also known as spreadsheet constraints). This is also how people understand when used practically. And of course dataflow is also where all this Rx stuff came from (see Messerschmitt's synchronous dataflow) 4. Yes, the synchronous dataflow languages Lustre and Esterel apparently can be and routinely are compiled to state machines. In fact, if I understood the papers correctly the synchronous dataflow languages are seen as a convenient way to specify state machines. 5. It would probably help if you added some links to your papers.

giovannibonetti 3y ago

A language/framework that explored well this idea is Elm, which is used in front-end apps. It started with Signals and FRP, then 7 years ago changed course to the Model-View Update architecture [1], today known as The Elm Architecture. It is still a bit niche, but a handful of frameworks in other languages like Rust are following this architecture for GUI apps. [1] https://elm-lang.org/news/farewell-to-frp https://elm-lang.org/news/farewell-to-frp