The fatal attraction of FRP(t0yv0.blogspot.com)
t0yv0.blogspot.com
The fatal attraction of FRP
http://t0yv0.blogspot.com/2014/07/the-fatal-attraction-of-frp.html
8 comments
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?
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?
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!
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!
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.
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.
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...
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...
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.
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.
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?
I'm sure I'm missing something, can it be explained in simpler terms, please?
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/
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/
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.
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.
OT, but, what happened to that budapest FP night?
I'd love to attend :)
I just moved to U.S. Check out http://www.meetup.com/fp-bud/
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.
I was disappointed to see the article was not about Fiber Reinforced Plastics.
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/
[2] http://www.wisdom.weizmann.ac.il/~harel/papers.html
[3] http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...