Over-Reactive?
ThoughtWorks, in their April 2016 Technology Radar, write this bemusing sentence about reactive programming techniques:
While we like the pattern, overuse of event-based systems complicates program logic, making it difficult to understand; developers should use this style of programming judiciously.
These are familiar arguments against reactive programming which reactive programming advocates have heard time and time again: “It’s hard to understand.” “It’s overcomplicated.”
Reactive programming toolkits allow explicitly modeling and declaring logic about how values in a program change over time and input. Reactive code is written in a declarative manner, rather than an imperative one, freeing the programmer to focus on the program’s handling of data.
I argue that equivalent data flows expressed in traditional, imperative code, are more difficult to understand and reason about; logic about how the program handles and transforms data is mixed in with the minutia required in writing asynchronous delegate- or callback-based event handling code. This leads to code paths that are difficult to reason about or even to predict over time.
How many bugs are present in imperative asynchronous code? Unimaginably many, because as time moves forward the number of possible states—and possible code paths—for the program approaches infinity. Reactive programming, by explicitly declaring and enforcing data- and event-dependencies, helps constrain the number of possible program states over time.
I’ll argue, then, that:
Overuse of imperative code in event handling complicates program logic, making it difficult to understand; developers should use this style of programming judiciously.
— Chris Dzombak, 2016
The fact that a technique does not appear immediately familiar and useful to one programmer or team (here, apparently, the Thoughtworks Technology Radar authors) does not mean the technique in question is inherently overcomplicated or difficult to understand. What those making this argument often really mean is that the technique is “unfamiliar.”
Complex data flows, especially in an asynchronous environment, are complicated and hard; maybe the problem is there, not in a tool designed to help model and reason about them in a formal manner.