5 ms·

The fatal attraction of FRP

45 points by platz 12y ago

bagels 12y ago
FRP according to this article is "Functional Reactive Programming", which Wikipedia defines as "a programming paradigm for reactive programming using the building blocks of functional programming" I was disappointed to see the article was not about Fiber Reinforced Plastics.
carterschonwald 12y ago
This post does a pretty nice job articulating some of the really deep challenges in building a proper FRP system. Currently with current gen FRP, theres a rough trade off between generality of abstractions and strength of performance guarantees. That said, theres a LOT of smart folks attacking this problem from many angles, and I think if theres a way to get generality AND performance, someone will figure it out in the next decade.
michaelsbradley 12y ago
I agree. FRP is, sadly, a siren song (for the most part). I was enchanted by it back in 2011 when I began studying the source code for Flapjax[1] (the development of which goes back to 2006!). What I learned the hard way -- both trying to develop a "next gen" derivative and using it in my own projects -- is that it's all too easy to underestimate the pain of getting trapped in the monad, over and over again. FRP is not the answer. Clojure/Script's core.async is a better way to do reactive programming, and yet... a declarative and structural DSL which allows for little bits of imperative glue code with contracts and highly controlled effects, and which allows disparate components to "automagically" pass immutable messages without extra plumbing, that is the future. It's what I want to use for own projects, and I hope others will enjoy it as well. Work is in progress. David Harel[2] showed the way over two decades ago[3]. [1] https://github.com/brownplt/flapjax/ https://github.com/brownplt/flapjax/ [2] http://www.wisdom.weizmann.ac.il/~harel/papers.html http://www.wisdom.weizmann.ac.il/~harel/papers.html [3] http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...
- mpweiher 12y ago
  Glad to hear someone else use "siren call" to describe this :-) Interesting references to statecharts, I remember reading about them in the late 90ies and not much coming out of it. (Note that link [3] above is to an out-of-print book that can now be downloaded) How do you see constraints relating to this?
- a-saleh 12y ago
  Oh, will you elaborate on the pitfalls? :) I have just started using C# with RX extensions to do some ui work, and so far I liked it. But I have never utilized RX directly on managing event-streams, mostly for binding changing data to various ways of displaying it. Second thing, I don't think I have been "trapped in the monad", and as far as I can see, C# devs are quite fond of the pattern (i.e., isn't Task a monad, Observable as well?) Thanks!
  - michaelsbradley 12y ago
    So, I've been thinking about this, and the reality is that I'm not as familiar with C# and Rx as I should be to pass judgment. How common is it to use "await" in conjunction with Rx? Your answer will provide needed insight. I've mainly wrestled with the FRP paradigm in the context of JavaScript, both server-side and in browsers. So I should have qualified my previous observation accordingly.
riffraff 12y ago
OT, but, what happened to that budapest FP night? I'd love to attend :)
- t0yv0_ 12y ago
  I just moved to U.S. Check out http://www.meetup.com/fp-bud/ http://www.meetup.com/fp-bud/
lmeyerov 12y ago
I have criticisms of FRP implementations, but the supposed two fatal flaws proposed here seem wrong. 1: Static type support for causality. If this is referring to what I think it is, then it's something normal async code doesn't have to begin with. 2. Memory leaks: these are mostly symptoms of lazy programming a la Haskell, not about FRP. Once you eliminate this bug of Haskell's, the significant ones go away. For avoiding them in practice, try FrTime (scheme), Flapjax (javascript), and Rx's "hot" streams (most languages). Edit: for those proposing tasks, that's about something different. The loose answer to tasks are promises. FRP is about a more expressive (multiple assignment scenario) and structured (more synchronized) promise.
pestaa 12y ago
I'm just starting out with Elm.js so I couldn't fully understand the article. However, it seemed to argue that keeping tons of event details in memory will exhaust memory, which is obvious. I need to remember to throw away data I no longer need in other paradigms, too. I'm sure I'm missing something, can it be explained in simpler terms, please?
- deadfoxygrandpa 12y ago
  There are different types of FRP implementations. In Elm terminology, monadic FRP allows the definition of a function join : Signal (Signal a) -> Signal a, which would allow you to dynamically create (and use) Signals at runtime. Now imagine you've defined a function that returns a Signal, like: clickCounter : () -> Signal Int clickCounter _ = count Mouse.clicks What happens if the runtime allows you to dynamically call this function and return separate instances of this click counter? Either the value held by the counter is dependent on when it was created, which breaks purity, or the runtime system has to keep track of every input event it's ever received, which is the cause memory usage to forever grow with time. Elm disallows the bind and join functions for Signals in favor of Applicative FRP (if you know Haskell, Elm's <~ and ~ operators correspond to the <$> and <*> operators of applicative functors in Haskell.) Other implementations get around this in other ways, such as ignoring purity. Elm's creator made this interesting presentation about different ways to resolve the issue: http://prezi.com/jqowmkidsrmy/the-taxonomy-of-frp/ http://prezi.com/jqowmkidsrmy/the-taxonomy-of-frp/
mpweiher 12y ago
Yes, there is something there that is attractive and that many developers sense is needed. However, I think we are still struggling as a community to figure out what exactly it is. I am pretty sure FRP is not it, though. I still dataflow constraints (and possibly just Lucid/Lustre style dataflow) are a good option. Longer discussion: The Siren Call of KVO and (Cocoa) Bindings[1], which talks about other solutions that don't quite work, but also about FRP. [1] http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...
moogoo 12y ago
FRP == Monads gone wild

45 points by platz 12y ago

FRP according to this article is "Functional Reactive Programming", which Wikipedia defines as "a programming paradigm for reactive programming using the building blocks of functional programming" I was disappointed to see the article was not about Fiber Reinforced Plastics.

carterschonwald 12y ago

This post does a pretty nice job articulating some of the really deep challenges in building a proper FRP system. Currently with current gen FRP, theres a rough trade off between generality of abstractions and strength of performance guarantees. That said, theres a LOT of smart folks attacking this problem from many angles, and I think if theres a way to get generality AND performance, someone will figure it out in the next decade.

michaelsbradley 12y ago

I agree. FRP is, sadly, a siren song (for the most part). I was enchanted by it back in 2011 when I began studying the source code for Flapjax[1] (the development of which goes back to 2006!). What I learned the hard way -- both trying to develop a "next gen" derivative and using it in my own projects -- is that it's all too easy to underestimate the pain of getting trapped in the monad, over and over again. FRP is not the answer. Clojure/Script's core.async is a better way to do reactive programming, and yet... a declarative and structural DSL which allows for little bits of imperative glue code with contracts and highly controlled effects, and which allows disparate components to "automagically" pass immutable messages without extra plumbing, that is the future. It's what I want to use for own projects, and I hope others will enjoy it as well. Work is in progress. David Harel[2] showed the way over two decades ago[3]. [1] https://github.com/brownplt/flapjax/ https://github.com/brownplt/flapjax/ [2] http://www.wisdom.weizmann.ac.il/~harel/papers.html http://www.wisdom.weizmann.ac.il/~harel/papers.html [3] http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...

mpweiher 12y ago
Glad to hear someone else use "siren call" to describe this :-) Interesting references to statecharts, I remember reading about them in the late 90ies and not much coming out of it. (Note that link [3] above is to an out-of-print book that can now be downloaded) How do you see constraints relating to this?
a-saleh 12y ago
Oh, will you elaborate on the pitfalls? :) I have just started using C# with RX extensions to do some ui work, and so far I liked it. But I have never utilized RX directly on managing event-streams, mostly for binding changing data to various ways of displaying it. Second thing, I don't think I have been "trapped in the monad", and as far as I can see, C# devs are quite fond of the pattern (i.e., isn't Task a monad, Observable as well?) Thanks!
- michaelsbradley 12y ago
  So, I've been thinking about this, and the reality is that I'm not as familiar with C# and Rx as I should be to pass judgment. How common is it to use "await" in conjunction with Rx? Your answer will provide needed insight. I've mainly wrestled with the FRP paradigm in the context of JavaScript, both server-side and in browsers. So I should have qualified my previous observation accordingly.

riffraff 12y ago

OT, but, what happened to that budapest FP night? I'd love to attend :)

t0yv0_ 12y ago
I just moved to U.S. Check out http://www.meetup.com/fp-bud/ http://www.meetup.com/fp-bud/

lmeyerov 12y ago

I have criticisms of FRP implementations, but the supposed two fatal flaws proposed here seem wrong. 1: Static type support for causality. If this is referring to what I think it is, then it's something normal async code doesn't have to begin with. 2. Memory leaks: these are mostly symptoms of lazy programming a la Haskell, not about FRP. Once you eliminate this bug of Haskell's, the significant ones go away. For avoiding them in practice, try FrTime (scheme), Flapjax (javascript), and Rx's "hot" streams (most languages). Edit: for those proposing tasks, that's about something different. The loose answer to tasks are promises. FRP is about a more expressive (multiple assignment scenario) and structured (more synchronized) promise.

pestaa 12y ago

I'm just starting out with Elm.js so I couldn't fully understand the article. However, it seemed to argue that keeping tons of event details in memory will exhaust memory, which is obvious. I need to remember to throw away data I no longer need in other paradigms, too. I'm sure I'm missing something, can it be explained in simpler terms, please?

deadfoxygrandpa 12y ago
There are different types of FRP implementations. In Elm terminology, monadic FRP allows the definition of a function join : Signal (Signal a) -> Signal a, which would allow you to dynamically create (and use) Signals at runtime. Now imagine you've defined a function that returns a Signal, like: clickCounter : () -> Signal Int clickCounter _ = count Mouse.clicks What happens if the runtime allows you to dynamically call this function and return separate instances of this click counter? Either the value held by the counter is dependent on when it was created, which breaks purity, or the runtime system has to keep track of every input event it's ever received, which is the cause memory usage to forever grow with time. Elm disallows the bind and join functions for Signals in favor of Applicative FRP (if you know Haskell, Elm's <~ and ~ operators correspond to the <$> and <*> operators of applicative functors in Haskell.) Other implementations get around this in other ways, such as ignoring purity. Elm's creator made this interesting presentation about different ways to resolve the issue: http://prezi.com/jqowmkidsrmy/the-taxonomy-of-frp/ http://prezi.com/jqowmkidsrmy/the-taxonomy-of-frp/

mpweiher 12y ago

Yes, there is something there that is attractive and that many developers sense is needed. However, I think we are still struggling as a community to figure out what exactly it is. I am pretty sure FRP is not it, though. I still dataflow constraints (and possibly just Lucid/Lustre style dataflow) are a good option. Longer discussion: The Siren Call of KVO and (Cocoa) Bindings[1], which talks about other solutions that don't quite work, but also about FRP. [1] http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...

moogoo 12y ago

FRP == Monads gone wild