4 ms·

How does flow-based programming compare with functional reactive programming, like Elm [1] and Bacon.js [2]? Could those be made visual with a graph editor like

by meemoo 13y ago

How does flow-based programming compare with functional reactive programming, like Elm [1] and Bacon.js [2]? Could those be made visual with a graph editor like this? Bacon.js has some flow diagrams [3] to describe some of its advanced concepts. 1. http://elm-lang.org http://elm-lang.org 2. https://github.com/baconjs/bacon.js https://github.com/baconjs/bacon.js 3. https://github.com/baconjs/bacon.js/wiki/Diagrams https://github.com/baconjs/bacon.js/wiki/Diagrams

michaelsbradley 13y ago
Also see Flapjax: http://www.flapjax-lang.org/docs/ http://www.flapjax-lang.org/docs/ https://github.com/brownplt/flapjax/ https://github.com/brownplt/flapjax/ The programming behind the JavaScript library is really solid, and was most actively developed from 2006 through 2009. It never caught on, possibly because the mental model required for successfully hacking with "event streams" and "behaviors" is decidedly a functional one, and those concepts are quite abstract to begin with (more so than objects and prototypes). Also, studying the implementation is not for the faint of heart. On top of that, I don't think any big names got behind it and there wasn't exactly a marketing campaign. Ahead of its time? Definitely. And it's probably still worth looking into as an alternative when trying to choose among the various reactive libraries that have popped up in the last year or so.
johnpmayer 13y ago
Elm could do this, and it would also benefit from a graph editor that knew about the types
chipsy 13y ago
FRP is very similar in nature to FBP. (even the acronyms are similar) The main difference is in packaging. The original FBP systems were still 70s-style near-metal code within the component design, but the architecture described a protocol just sufficient for statically and asynchronously connecting the components together, and a runtime method that is amenable to the simplistic approach of having each component run round-robin until all return a "finished" signal. It's very much an "industrial engineering" perspective. FRP, on the other hand, comes from the traditions of functional programming, and so the evaluation order computation is given a more academic treatment, and the languages are given more explicit syntax, where FBP doesn't aim to describe itself much more deeply than the flowcharts. Both FRP and FBP have purity and immutability as core concepts. So as I see it: different starting point, different packaging, same conclusions.

by meemoo 13y ago

michaelsbradley 13y ago

Also see Flapjax: http://www.flapjax-lang.org/docs/ http://www.flapjax-lang.org/docs/ https://github.com/brownplt/flapjax/ https://github.com/brownplt/flapjax/ The programming behind the JavaScript library is really solid, and was most actively developed from 2006 through 2009. It never caught on, possibly because the mental model required for successfully hacking with "event streams" and "behaviors" is decidedly a functional one, and those concepts are quite abstract to begin with (more so than objects and prototypes). Also, studying the implementation is not for the faint of heart. On top of that, I don't think any big names got behind it and there wasn't exactly a marketing campaign. Ahead of its time? Definitely. And it's probably still worth looking into as an alternative when trying to choose among the various reactive libraries that have popped up in the last year or so.

johnpmayer 13y ago

Elm could do this, and it would also benefit from a graph editor that knew about the types

chipsy 13y ago

FRP is very similar in nature to FBP. (even the acronyms are similar) The main difference is in packaging. The original FBP systems were still 70s-style near-metal code within the component design, but the architecture described a protocol just sufficient for statically and asynchronously connecting the components together, and a runtime method that is amenable to the simplistic approach of having each component run round-robin until all return a "finished" signal. It's very much an "industrial engineering" perspective. FRP, on the other hand, comes from the traditions of functional programming, and so the evaluation order computation is given a more academic treatment, and the languages are given more explicit syntax, where FBP doesn't aim to describe itself much more deeply than the flowcharts. Both FRP and FBP have purity and immutability as core concepts. So as I see it: different starting point, different packaging, same conclusions.