Wonderful. I’ve long thought of process philosophy as the philosophic underpinning of FRP, but I was focused more on the problem of identity.
This article is simply adding more confusion to the current state of affairs regarding FRP.
Don’t get me wrong–I don’t subscribe to the school of thought that only the creator of a thing gets to determine its path and definition, but reading through an article on FRP without once seeing a reference to any of the substantial work done in this area is infuriating.
If you’re going to talk about a thing and proclaim some expertise on it to the degree that you think you can explain it, take (author of Elm) Evan Czaplicki’s lead and do your homework without complaining about “the rabbit-hole of monads, functors and other technical jargon.” That “technical jargon” is in there because people actually worked hard to describe something concretely in terms that allowed for a specific understanding and implementation of the concept.
Here are some good resources to start with if you actually want to learn about some of the different formulations of FRP that aren’t just hand-wavy:
http://begriffs.com/posts/2015-07-22-essence-of-frp.html (Conal Elliott describes his conception of FRP)
http://stackoverflow.com/a/1030631 (ditto, but in an Stack Overflow answer)
http://elm-lang.org/papers/concurrent-frp.pdf (good description of precedents and various tradeoffs in the beginning)
https://www.youtube.com/watch?v=Agu6jipKfYw (talk on FRP by Elm creator)
http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgbk-flapjax/paper.pdf (JS implementation of FRP informed by precedents)
I thought this article was much more approachable than Conal Elliott’s talk. dmvaldman made FRP into a pretty relatable concept, for me anyhow. Elliott’s, on the other hand, was quite technical.
I don’t debate that the linked piece is more approachable…but how does it relate to Conal Elliott and Paul Hudak’s original formulation of FRP or any of the formulations that came after that in response?
without once seeing a reference to any of the substantial work done in this area is infuriating.
Is everything that mentions a thing required to cite everything it’s ever built upon?
No, of course not, but please allow me to try to persuade you that the author is failing to connect their concept of FRP to the original notion and the formulations which came after, and being confusingly vague otherwise, at the expense of the reader’s understanding.
For example, the author makes the statement in the “Implementation and Design” section that
This is fundamental to FRP: no computation is wasted on changes that are not observed. You get performance for free.
They seem to be implying that this has some relationship to how the ordering of events in physical reality is inverted when implementing ray tracing, and this has implications for performance. However, I don’t feel like I have any understanding of why this is; the author doesn’t explain this other than to imply that because ray tracing is more performant (than simulating reality I assume, since as far as I understand ray tracing’s strength is not in how performant it is but in how realistic its results are), and the ordering of events in FRP is analogous to the ordering of events in raytracing, therefore we get performance for free in FRP.
However, even leaving aside the problematic aspects of the above statement, if you read Conal Elliott’s summary on stackoverflow which I linked to in my previous post, you’ll note that he ends with
It’s been quite a challenge to implement this model correctly and efficiently, but that’s another story.
Further investigating, if you read Evan Czaplicki’s paper on Elm, you’ll note that he talks about the challenges of implementing FRP using continuous semantics vs. discrete, and talks about how
Concurrent FRP solves some of FRP’s long-standing efficiency problems: global delays and needless recomputation.
Unnecessary updates are caused by discrete inputs, such as mouse clicks. Continuous signals assume that signal values are always changing.
…etc–he goes on with a thorough analysis, and Elm itself is in fact (in part) an attempt to mitigate some of these issues. And if you follow the thread you’ll note that Conal Elliott re-formulated FRP in his paper Push-Pull FRP to address issues of efficient implementation. The first statement in the abstract is
Functional reactive programming (FRP) has simple and powerful semantics, but has resisted efficient implementation.
So, how does this square with the original piece’s author’s claim that in FRP “no computation is wasted on changes that are not observed. You get performance for free?” I have no idea–it sounds to me as though the author is talking about something completely different than what Elliott and Czaplicki are talking about. I see only the most tenuous connection between what the author describes and the original conception of FRP.
Therefore I hope you’ll understand why I find this frustrating and why I think it’s bad for people trying to understand what FRP actually is–in the end, as someone who himself has struggled to understand FRP and trace its lineage and development through different stages, I find that this piece is muddying the waters, not illuminating anything.
I know that it’s unreasonable to expect a term to be used consistently once it enters the general collective consciousness of the programmer-culture/industry matrix: terms get twisted and diluted to suit a easy-to-understand or profitable version of that thing. Look at the term “object-oriented programming” for the perhaps canonical example of this.
But I hope I can at least be forgiven for pointing out the inconsistencies here as I see them. I think we would benefit, as a community, from consistently applying critical thinking to pieces like this.
(edited for grammar)
Having more or less read this article, I can now agree with @ddellacosta that the article was written by somebody who doesn’t know what FRP is; instead, they have confused FRP with a particular style of asynchronous event notification which could be used to implement either FRP or non-FRP systems, and which FRP systems can be implemented with or without. It is the programming equivalent of explaining that an “automobile” is a piece of steel with unusually high vanadium content.