Hacker News Reader

Comment by danharaj | Hacker News Reader

None of this is functional reactive programming as originally formulated by Conal Elliott and Paul Hudak, which in particular emphasized the need to model reactive programs as the algebraic composition of simple abstract units, events and behaviors. If you have to set up a listener for an event, you aren't doing FRP, you're just doing Reactive Programming.

View on HN

This same discussion comes up every time FRP is mentioned, because most articles that say they are about FRP are about Reactive Programming using Functional methods. You can keep bring it up every time you see such a post, but maybe it's better for your own sanity to just realise that ship has sailed: when people write about FRP, they write about this.

As Elliott himself suggested [0], it might be a good idea to use the term DCTP when talking about the concept you're talking about. Yes, it might feel wrong because his FRP was "first", but at least it's clear.

> To reduce confusion, I would like to see the term “functional reactive programming” replaced by the more accurate & descriptive “denotative, continuous-time programming” (DCTP)

[0] http://stackoverflow.com/questions/5875929/specification-for...

My job is to write actual FRP so it's no sweat for me to vigorously complain every time that people are stealing "my" term :p

While Conal may have distanced himself from FRP, in the Haskell FRP community that's what we still call it.

Haha, well, if it's no effort for you to keep it up, then by all means, keep it up :) Just don't expect it to actually change :P

DCTP ?

Unfortunately a very common mixup. Here is Erik Meijer (aka headinthebox), the main guy behind Rx, talking about the difference[1]:

Let's keep "FRP" for what it really stands for in honor of it's inventor (http://conal.net/talks/). Rx is not FRP and was explicitly designed as a discrete collection API on purpose (as opposed to continuous time varying values). ...

[1] https://github.com/ReactiveX/reactivex.github.io/issues/130

Of course Conal no longer likes the name Functional Reactive Programming for what he did. And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming.

Sigh.

> And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming.

well, dataflow programming has always been central to reactive programming, isn't it ? that's what all reactive languages, Esterel, Lustre, etc. were about.

Yes, that's what I am saying, or rather: it's not "central to it", it is the thing itself.

"Reactive" is really just a re-branding of (synchronous) dataflow programming, and a fairly bad one at that because it just jumbles up and confuses so many things.

"Reactive" is/was really a type of system: one where you have continuous interaction with the outside world and the world generally cannot wait (similar but not identical to real-time). Contrasting with "transformational", where you just get some inputs turn them into outputs and are done, and "interactive", where you interact with the outside world but the world can wait.

It turned out that the synchronous dataflow languages (like Esterel, which is imperative, and Lustre, which is functional) had some fairly nice properties when it came to building reactive systems. As far as I know, Esterel is used for Airbus avionics...so the outside world really, really cannot wait :-)

How people somehow managed to mix up the style of system with the technology and then somehow also put in a claim that "functional" was an essential part of it is a little beyond me.

> ... were about.

are about.

This has been very frustrating to me because it feels like many reactive frameworks for OOP languages are actively muddying the waters. I've had stuff like ReactiveX recommended to me as "FRP" and it's nothing like the form, and just wastes my time.

If actual FRP for web wasn't doing so relatively well, I would begin to fear that FRP is heading the same way OOP did after Smalltalk, a shadow of the actual thing pushed as a buzzword to sell to marketing managers with no clue or concern about the actual tech.

And god help me, I do not want to see what the C++ of FRP looks like ...

> And god help me, I do not want to see what the C++ of FRP looks like ...

plenty of reactive libs in there. The original one was Qt with the signal system. More recent research in this domain is for instance RaftLib : https://github.com/RaftLib/RaftLib/blob/master/examples/gene...

Not quite the analogy I was alluding to. Ie. not so much "FRP in C++" as "C++ : OOP :: ___ : FRP."

Though I grant you that C++ could just as easily wind up filling both blanks.

judging from where i work, that has already happened to a large degree, and i would guess elsewhere too... as alan kay would say "its all a pop culture"

edit: spelling mistake

Nice talk by Conal Elliott on the original formulation:

https://www.youtube.com/watch?v=j3Q32brCUAI

Reply on news.ycombinator.com