The Functional Reactive Misconception
Swift is around since more than a year now hated or loved by developers, creating the feeling there’s no in-between state. The nature of the language is general: first-class functions, generics, tuples, etc… a lot of nice things that other languages have since some years are now available to developers that are writing software for Apple platforms. All these features are key things to make Reactive Programming enjoyable and easy, but… there’s one misconception that is very common and could drive to misunderstandings: it’s the usage of the terminology Functional Reactive Programming for almost any reactive framework.
Reactive Programming is not (only) Functional
The story is old:
Functional Reactive Programming is Reactive Programming, but not every implementation of Reactive Programming is functional.
Let’s make this clear.
Definition of Reactive programming is very dated, the first paper to give a definition about a Reactive system is “the synchronous dataflow programming language Lustre”.
There are many different definitions around the web, from dated technologies like the mentioned LUSTRE, passing through Ada and ending with the recent Reactive Manifesto. All these definitions are slightly different between each other, so which one is correct? All of them! It depends on the context where the definition is used and is always a good habit to make clear which definition we are referring to.
I would like to give a short definition about what reactive programming means and the difference from the classic imperative approach: Reactive Programming is about propagating changes while declaring what to do to achieve a certain behavior when the given value changed, rather than how to achieve the desired behavior.
Quick example: if I have the following metacode:
a = 4, b = 5 c = a + b b = 6 print(c)
In imperative programming the print will display the number
9, in reactive programming the result will be
10. This means that
c is evaluated every time one of the 2 variables in the expression has changed, on the opposite, with the imperative approach,
c is evaluated only once and will never change if not re-assigned. The fundamental of reactive is this and a good example is a spreadsheet like Excel or Numbers, where the change of a value in a cell is immediately propagated.
There’s a lot more in the definition about what Reactive means, but I would stop here. Other definitions are about being resilient, scalable, etc… but for the meaning of this article, these definitions are not interesting.
Functional Reactive Programming
If you think FRP is just Reactive Programming with Functional style, let me say that unfortunately this is not the case. Functional Reactive Programming is a formulation created in 1999 by Conal Elliott and Paul Hudak and is defined in a paper titled “Functional Reactive Animations”. The definition is about a denotative, continous-time collection of functions and types. The paper explains what Functional Reactive Programming is and in a nutshell: FRP is denotative and temporally continuous.
To better understand what FRP is, I would suggest to read the linked paper, the slides about FRP and eventually two nice answers of Conal on Stackoverflow:
- Essence and Origins of FRP - (Video)
- What is (functional) reactive programming?
- Specification for a Functional Reactive Programming language
FRP Implementations in Swift
The big question now is: how many implementations are around actually using FRP as core concepts? The answer is: very few.
As far as I know, there’s not a single (100% valid) implementation of FRP principles in Swift. There’s one implementation of FRP principles in Swift called SimpleSwiftFRP, the framework has a denotational semantics as well. This makes this project a good reference to learn FRP.
In other languages like Haskell or Elm, there are implementations of FRP in the classic way and I would suggest to eventually check these resources, like Reactive-Banana, to better understand what FRP is… or you can also wait for the “Reactive Programming in Swift” book. :P
Reactive Programming in Swift
Now that, I hope, the difference between FRP and Reactive Programming is clear, I can list some reactive frameworks for Swift:
- Reactive Cocoa 3.0: RAC is a very famous reactive framework for Objective-C and Swift, currently in his 3.0 cycle, the framework is reported as inspired by FRP. Except for the naming convention, the framework has very little to share with the original work of Conal Elliott. RAC has HUGE community, a lot of articles, books and traction, it’s definitely the elephant of reactive programming in the Cocoa world.
- RxSwift: RxSwift is a port of the Reactive Extensions from the .NET world. Created by Erik Meijer, Rx has gained so much attention for the high level of abstraction the implementation gives and how easy is to deal with them. The project is few months old, but it has recently being migrated under the ReactiveX organization, making this project the official port of Rx for Swift.
- Interstellar: Interstellar is a very young, extremely basic implementation of the Signal abstraction. Also reported as inspired by FRP, this solution shares few things with the original definition, but offers an interesting start point to understand reactive programming with its simple codebase.
- SwiftBond: Born as binding framework, is now trying to switch in the Reactive space adding a new solution. This implementation is more similar to the Reactive Extensions rather than FRP, I would suggest to give it a try.
Reactive Programming and Functional Reactive Programming are two things, the latter is part of the former, but very few implementations are time-continuous with a denotative semantics.
It’s time to use the right definition for what we have in Swift, Reactive Programming and…
Let’s keep “FRP” for what it really stands for in honor of it’s inventor. Rx is not FRP and was explicitly designed as a discrete collection API on purpose (as opposed to continuous time varying values). – headinthebox
Edit 1: Conal Elliott kindly answered to an issue/PR I opened in Github on the RxSwift repository, I edited some links to reflect his suggestions for better resources. Thanks also to @RossBencina for suggesting the video of the talk.
Edit 2 (17.08.2015): Added SimpleSwiftFRP project.