Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

Neither Rx nor Elm are FRP. If you want FRP, look at Conal Elliott's work.

I haven't looked at Elm deeply, but last time I took a look it seemed to be very much FRP. What do you think it is missing?

This pedantic distinction isn't useful to anyone, please stop Well Actually'ing people

It's not a pedantic distinction given how much the term has been overloaded to refer to dissimilar concepts.

We should just have separate terms for Discrete vs Continuous flavors instead of fighting over the one true "FRP"

It's not just that. Elm and Rx lack continuous value streams at all, they are completely discrete; also they are very much asynchronous, so they are more like the event stream manipulation done via data flow in the 70s rather than what Elliott and Hudak invented in the late 90s.

For something to be called FRP, they at least need both continuous and discrete abstractions; the simplest description of FRP involves re-evaluation A + B over time, which is not meaningful in Rx or Elm, really.

It's meaningful in Elm.

I would love to see an example. I've browsed Evans' thesis, and it seems like he explicitly avoids continuous abstractions (behaviors) for event processing.

Here is an example: http://elm-lang.org/edit/examples/Reactive/Position.elm

In Elm behaviors and events are the same thing. Usually operations like filter and fold are only on events, and applicative functor and monadic operations are only on behaviors, but in Elm one type support filter and fold and the applicative functor operations, and monadic bind is not supported at all. I don't think that's good design, but it does mean that Elm has the functionality of both events and behaviors.

Will do. Thanks for the pointer. Do you have any suggestions offhand?

Start at the beginning:

http://conal.net/fran/tutorial.htm

Warning: FRP is much more purest than Rx (which is just data flow) or Elm (which is more FRPish but asynchronous). You probably don't want FRP but something more pragmatic like the fore mentioned systems.

From what I understand, although Conal Elliot coined the term FRP first in a relatively narrow sense, today the term FRP is used much more freely to describe reactive programming using functional building blocks (especially combinators like map, filter etc.).

There are some nice papers that give an overview of the FRP landscape.

“A Survey on Reactive Programming”: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.416...

“Towards Reactive Programming for Object-oriented Applications”: http://www.guidosalvaneschi.com/attachments/papers/2014_Towa...

These papers actually look readable. I'll give them some time, thanks for posting!

This is not true at all. It is only recently and only in the SF hacker bubble that FRP has been co-opted to mean anything that is functional, reactive, and programmed.

Outside, FRP still means FRP, and using the term will automatically put your work in a certain specific bucket that you might not want to be in.

Reply on news.ycombinator.com