Reactive Programming and the Reactive Manifesto
In July of last year, Jonas Bonér and some other colleagues published the Reactive Manifesto. Soon, the term was on everyone's lips, but this seemingly new programming concept is actually much older.
The term Reactive Programming was coined by David Harel and Amir Pnueli back in 1985 . Harel and Pnueli focused their academic work on designing systems that must constantly respond to input or changes. Over the following years, the meaning of the term reactive programming shifted slightly. Today, an application is generally considered reactive if it responds quickly to input or data changes.
If you investigate the existing solutions that specialize in reactive programming, you will encounter a mix of terms, concepts, and implementations. Jonas Bonér and his co-authors wanted to clear up this confusion with their Reactive Manifesto . Bonér and many of his colleagues work for Typesafe, which provides a platform for reactive programs , so the authors have a strong incentive to advance the prospects of reactive programming.
The Reactive Manifesto defines common terms that improve collaboration among the developer communities and also make it easier for users and manufacturers to talk to each other. According to the manifesto, a reactive program:
- Reacts to events – Even-driven nature emphasizes data flow and is easily extendable
- Reacts to load – Focuses on scalability by avoiding contention on shared resources
- Reacts to failure – Has ability to recover from an error or unexpected situation
- Reacts to users – Honors response time guarantees regardless of load
Reactive programming is especially useful with interactive programs, robotics controllers, web applications, and programs that analyze large amounts of data. Wherever a program needs to provide an answer within a few milliseconds, or must operate with high efficiency under large data volume, reactive techniques offer a compelling alternative. Because these requirements apply to more and more applications, it is not surprising that more projects are focusing on reactive programming.
Always on the Move
Programmers often need to perform a computation and store the result in a new variable. A simple example:
In most programming languages, the contents of the
a variable remain constant until the program explicitly takes an action to change it – even if the contents of
b change. In other words, if
a will no longer equal
b+2 unless the program repeats the operation.
In contrast, reactive programming insists on the variables
b remaining dependent on each other: once
a is automatically updated. The variable
a thus always contains the value of
b+2, regardless of the value of
b. A programmer does not have to think about where to repeat the computation. This approach reduces the sources of error and allows the application to respond faster. In this sense, you can think of the term
reactive programming as
Whereas developers in conventional languages concentrate on the control flow (i.e., the command sequence), data flow is typically in the foreground for reactive programming. The event-driven nature of reactive programming lends itself to parallel processing: The more processors an application can involve, the faster it performs its computations – at least in theory.
If the components of an application run concurrently, reactive programming makes it easier to run the program on distributed systems or in the cloud. Asynchronous data processing also helps with complex execution scenarios: After the user interface has sent the changed data to the database, the program does not wait for an answer but is immediately available for more input.
With its view toward data flow rather than commands, reactive programming is easy to integrate with existing languages. In object-oriented programming, for example, you can pass in data changes using the Observer design pattern . This is the path that Microsoft takes with its Rx library, which adds reactive programming to the .NET world (Figure 1) .
A Java port goes by the name of RxJava and comes from the online video store, Netflix . For most other important languages, appropriate libraries or extensions already exist. Ruby has Frappuccino , and while Sodium  supports reactive programming in Java, Haskell and C++.
Elm does not use variables in the conventional sense. In addition to constants:
a = 2 + 4
Elm supports signals. Signals behave like variables but can suddenly change value. A prime example of this is the
Mouse.position signal, which always contains the current coordinates of the mouse pointer. If the programmer includes
Mouse.position in a computation, Elm automatically updates the result after a mouse movement. This behavior is easily illustrated by outputting the mouse position on the screen (Figure 5). The source code for outputting the mouse position contains just two lines:
import Mouse main = lift asText Mouse.position
import includes the library with the mouse functions and signals. The
lift function then dumps the current mouse coordinates from
Mouse.position into the
asText function. The
asText function, in turn, translates the numeric value into text. The text is then pushed into the special constant
main, and the contents appears on the screen. The
lift function is necessary to apply a normal function to the signal. Elm refers to this process as lifting. The result is again a signal.
lift itself assumes that the function (in this case
asText) only expects one parameter. If the function requires two parameters, the programmer must use
lift3 for three parameters, and so on.
You can try out the code directly in the browser: The Elm developer provides a small development environment on the website . You type the code on the side, and after clicking on Compile (bottom left in the window), the result – or an error message – immediately appears on the right.
Apart from its unusual
lift function, Elm is little reminiscent of Haskell or CoffeeScript. Thanks to the libraries included with Elm, you can quickly implement client applications in the browser; signals predestine Elm for building interactive user interfaces right from the outset. In contrast to many other functional programming languages, however, the transition from imperative languages is quite simple. For a quick and easy-to-understand introduction, check out the online documentation . The sample collection  shows what is possible with Elm. For example, you can change the diagram in Figure 6 with the mouse in real time; a complete pong game requires only 100 lines of code . However, Elm still down not appear in any serious practical applications.
One for All
According to the manifesto, an application is considered reactive if it can respond immediately to a stimulus. To this end, all the software components must be event-driven, scalable, resilient, and responsive. In a web application, for example, not just the client browser but also the server components must respond quickly; otherwise, the entire system grinds to a halt.
The components of a reactive application can only communicate with each other via events (message passing); they must also send and receive asynchronously. This mandatory requirement ensures that the components run concurrently and thus that the application scales more easily.
Blocking operations are forbidden. If a thread grabs exclusive access to a resource, other threads have to wait, and in the worst case, this prevents any further execution of the application. To avoid such situations, the manifesto prohibits blocking operations, synchronization, and resource hogging. The intent is for the system to use this approach to achieve lower latency and higher throughput under heavy load. Any necessary synchronization should be handled by the runtime environment. Developers only have to deal with how the individual components of their applications interact.
To prevent bottlenecks occurring somewhere at high load, it is important for the complete system to work asynchronously and in a non-blocking way. In other words, not only must the GUI be able to handle asynchronously transmitted events, but also the middleware, right down to the underlying database. The authors of the manifesto call for programs to be "reactive from top to bottom." If you follow all the rules, your application can display the official "We Are Reactive" banner (Figure 3).
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?