3 ms·

I'm just happy someone for one wrote one of these things and properly distinguished FRP as being different from "reactive programming" generally.

by tel 12y ago

pron 12y ago
FRP is no more than reactive programming (sometimes known as dataflow programming) using a pure-functional programming style rather than an imperative style. It's just that the term "reactive programming" itself has been hijacked by some to mean something else entirely (roughly: concurrent, low-latency programs in general).
- seanmcdirmid 12y ago
  If we go back to the 80s and the original reactive programming languages designed for embedded systems (which inspired FRP), we can see even more differences. In systems, there is a big push for (and against) "event-based programming" models with respect to concurrent and distributed systems; e.g. see: https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf https://www.usenix.org/legacy/events/hotos03/tech/full_paper... where the definitions are even more different.
  - pron 12y ago
    Ah, yes. That paper (among other things) inspired me to implement true lightweight threads on the JVM. I also use some of the arguments in that paper to demonstrate that while pull and push are technically duals, in practice, pull APIs are always superior (except, again, in referentially transparent languages that lack the concept of a stack and a thread).
    - seanmcdirmid 12y ago
      I've been writing.designing reactive programming languages and frameworks for more than 10 years now, I started out with Superglue in my dissertation: http://lampwww.epfl.ch/~mcdirmid/papers/mcdirmid06superglue.pdf http://lampwww.epfl.ch/~mcdirmid/papers/mcdirmid06superglue.... Early on, I realized that pull was the only safe/sane solution, so in all my languages (barring early versions of Superglue), change propagation merely dirties execution that could have read the changed value, which is queued to be re-executed and will pull the new value if it still depends on it. That is the style that I use for Glitch, and it has turned out to be very robust. Push is much harder. Actually, I'm not even sure how those systems even work properly; too many things to coordinate.
- tel 12y ago
  I believe that. I suppose I specifically cringe whenever I see FRP described via event networks and things of that nature—implementation not denotation.

I'm just happy someone for one wrote one of these things and properly distinguished FRP as being different from "reactive programming" generally.

by tel 12y ago

I'm just happy someone for one wrote one of these things and properly distinguished FRP as being different from "reactive programming" generally.

pron 12y ago

FRP is no more than reactive programming (sometimes known as dataflow programming) using a pure-functional programming style rather than an imperative style. It's just that the term "reactive programming" itself has been hijacked by some to mean something else entirely (roughly: concurrent, low-latency programs in general).

seanmcdirmid 12y ago
If we go back to the 80s and the original reactive programming languages designed for embedded systems (which inspired FRP), we can see even more differences. In systems, there is a big push for (and against) "event-based programming" models with respect to concurrent and distributed systems; e.g. see: https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf https://www.usenix.org/legacy/events/hotos03/tech/full_paper... where the definitions are even more different.
- pron 12y ago
  Ah, yes. That paper (among other things) inspired me to implement true lightweight threads on the JVM. I also use some of the arguments in that paper to demonstrate that while pull and push are technically duals, in practice, pull APIs are always superior (except, again, in referentially transparent languages that lack the concept of a stack and a thread).
  - seanmcdirmid 12y ago
    I've been writing.designing reactive programming languages and frameworks for more than 10 years now, I started out with Superglue in my dissertation: http://lampwww.epfl.ch/~mcdirmid/papers/mcdirmid06superglue.pdf http://lampwww.epfl.ch/~mcdirmid/papers/mcdirmid06superglue.... Early on, I realized that pull was the only safe/sane solution, so in all my languages (barring early versions of Superglue), change propagation merely dirties execution that could have read the changed value, which is queued to be re-executed and will pull the new value if it still depends on it. That is the style that I use for Glitch, and it has turned out to be very robust. Push is much harder. Actually, I'm not even sure how those systems even work properly; too many things to coordinate.
tel 12y ago
I believe that. I suppose I specifically cringe whenever I see FRP described via event networks and things of that nature—implementation not denotation.