The traditional solution for a reactive is the observer pattern, but in reality this does not always work. For example, 30% of all Adobe bugs were due to event handlers (Guido had a source for this, but I missed it) The answer is, of course, reactive programming.
An example of this is handling mouse input, where all mouse locations are (x,y) tuples and in reactive programming, this is modeled as a signal of int,int, and this is automatically updated by the language. They can be combined with other values, we can, for instance, just add 10 to the position of the mouse.
This approach has been gaining a lot of popularity lately: Rx, angular.js, reactive.js and Scala.react.
There are a lot of claims that reactive is better (easier, more declarative, better for program comprehension, consistency etc.) But, these claims, in particular the one on program comprehension, have never been evaluated. And, they are not obvious. In a paper on FlapJax (Meyeorvic), the authors even stated that their syntax might _not_ be easier.
Guido’s research is going to address that, with the following research questions:
Guido performed a study where the same group of 38 participants read a 10 programs, both in an OO version and and a reactive version. They could just read the code, they could not compile or use an IDE. They were then asked a number of questions on the code.
Turns out, reactive programs are easier to read, as participants got it correct more often on the reactive version:
For time, the results were inconclusive:
Finally, do programmers need higher programming skills for the reactive skills? No, says Guido. While for the OO version, you could see that better skills led to a higher score, but this did not hold for the reactive program:
Preprint is here: http://www.guidosalvaneschi.com/attachments/papers/2014_An-Empirical-Study-on-Program-Comprehension-with-Reactive-Programming_pdf.pdf