

The fatal attraction of FRP - platz
http://t0yv0.blogspot.com/2014/07/the-fatal-attraction-of-frp.html

======
michaelsbradley
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.htm...](http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html)

~~~
a-saleh
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
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.

------
mpweiher
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...](http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-
bindings.html)

------
carterschonwald
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.

------
pestaa
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
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/)

------
lmeyerov
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.

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

~~~
t0yv0_
I just moved to U.S. Check out [http://www.meetup.com/fp-
bud/](http://www.meetup.com/fp-bud/)

------
bagels
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.

