Why I cannot say FRP but I just did
The story of a useful acronym with overprotective parents
Functional Reactive Programming (FRP) is an increasingly popular acronym. Both reactive and functional programming are genuinely useful terms conveying ideas without formal rigor. FRP, however, is a radically strict term for a programming technique mathematically defined about 20 years ago.
People loosely use FRP to refer to reactive programming combined with functional programming techniques. However, they are all wrong. This terminology nitpicking has hurt the developer community, bringing confusion and fear of pronouncing those 3 letters. I have seen this confusion repeat itself multiple times, and I think restricting FRP to its original rigorous semantics does not help us communicate programming ideas.
I believe FRP should be a useful term for an idea, just like functional programming and reactive programming are.
Functional
Functional programming is a paradigm in which computation is expressed as evaluations of mathematical expressions. In this paradigm we avoid side-effectful functions and mutable data. Most programming languages I can think of provide a way of writing a pure mathematical function, for instance, the `square(x)` function. To some extent, the functional paradigm can be applied in any language, by using pure functions and avoiding (either with discipline or a type system) mutable data and side effects.
Haskell is functional programming to the extreme, but it is not the only vehicle for functional techniques. Clojure (and other LISP-based languages), OCaml, F# are a few functional programming languages to mention.
Functional techniques are ubiquitous, and it wouldn't be fair to limit the terminology "Functional programming" only to Haskell. It's an idea that can be understood and applied even without rigorous mathematics.
Reactive
Even though there isn't a widely-known accurate definition of "reactive programming", it still has been useful (for more than 20 years!) as a term to refer to listenable signals, data flow, and spreadsheet-like computations.
Reactive programming was first mentioned in a paper from 1989. It was vaguely defined with words, not mathematical rigor.
Transformational programs compute results from a given set of inputs; […] Interactive programs interact at their own speed with users or with other programs […]. Reactive programs also maintain a continuous interaction with their environment, but at a speed which is determined by the environment, not by the program itself. […] Real-time programs are usually reactive.
Since then, there has been alternative definitions of reactive programming [1] [2] [3], but they are often associated with the idea of streams of events which can be observed or can react to other event streams.
FRP is a forbidden term
Given the above meanings of reactive and functional, it would make sense to talk about "functional reactive programming" as a paradigm or an idea where you build applications using listenable event streams (or "signals"), creating and composing them using pure functions. But no, that's not specifically and precisely what FRP meant when it was first uttered on the face of the third rock from the sun.
"Original FRP" refers to denotational and continuous-time functional programming using behaviors and events.
Another term for "Original FRP" is Denotative, Continuous-Time Programming (DCTP). Anything that deviates a millimeter from what the FRP pioneer Conal Elliot defined is a terminology sin:
Conal's endeavors at excluding mentions of FRP if they are not following denotations and continous-time requirements are relentless. What is the reason behind this?
One would guess the "FRP classification" of libraries would be a meaningful categorization, with a pie chart resembling roughly this:
The above is not at all how reality is. Original FRP is a niche in the Haskell community (which is already a niche). The real pie chart looks more like this:
Conal's answer on StackOverflow links to a Haskell page listing some libraries. You would guess at least those libraries must be true FRP. Incorrect. Sodium is the first library on that list, yet this forum discussion makes it clear Sodium lacks the precise denotations required by true FRP. Any denotation sprinkled on top would mean a wrong approach, because true FRP is denotation-first.
This makes the term FRP essentially useless for most programmers, since it is only relevant to a niche-in-a-niche.
What alternatives do we have?
Given that "Functional" and "Reactive" are often useful together to describe a solution or library, I started using "F&RP" (it could have been also "RFP" or "R&FP"):
I am not alone when considering FRP as a term conveying an idea, rather than a specification.
Elm creator Evan Czaplicki gave a great presentation at Strangeloop, classifying the different flavors of "FRP", even though according to conservatives this is a paradox:
English is not a strict type system
The English language evolved and continues to evolve. We use words to convey meaning, but we also stretch and mutate both words and their meanings for multiple reasons. This process is human and inevitable.
As humans, we want to talk about ideas, and names are good ways of expressing these ideas. As Evan's presentation above shows, there are multiple tools (Fran, Yampa, Elm, Reactive Banana, Reactive Extensions, Bacon.js, ReactiveCocoa, Sodium) that all share one common idea: functionally-composable signals. By giving a name to a common idea, we make communication easier.
What name shall we give to the common idea? RFP? F&RP? R&FP? None of these are as widespread as FRP, which to many people already conveys the idea of listenable and functionally-composable event streams.
What are we going to do?
Ironically, I'll actually take Conal Elliott's advice he let slip in a StackOverflow answer:
To reduce confusion, I would like to see the term “functional reactive programming” replaced by the more accurate & descriptive “denotative, continuous-time programming” (DCTP)
Original FRP becomes DCTP and FRP can be vaguely used for functionally-composable signals.
Haters gonna hate, I'm claiming Reactive Extensions is FRP.
