These days, I keep running across references to this wonderful New Thing called ‘reactive programming’ so I spent a day researching this wonderful New Thing.

I worked with the Scala language when I played with Spark so I’ve had my initiation to the new functional programming world.

Now, I’m a gray beard and have been programming for several decades and I’ve seen New Things come and go. I’ve also noticed that New Things usually have been done before in one form or another, so, the thing I need to discover is what form this most recent New Thing is taking, how it is being applied, and what it is good for. Like all New Things, I expect it is not the solution to All Problems like the hype seems to make it out to be, but it is instead a solution for a particular problem in some environment. I need to discover when and how to apply this particular tool.

James Coglan’s talk at JSConf EU 2014 entitled Practical Functional programming: pick two, nicely steps through the process of converting if/then logic implementing a multi-stage, asynchronous task and converting it into event flows and functional/reactive form.

The original program is a state machine implemented with if/then statements. My experience is that when approaching a problem as a state machine, one first sees the few, straight-forward states and one says “this will be easy”. But, when dealing with multi-stage, asynchronous processes, once one considers error states, stage order problems, and stage failures, the state space explodes and many of the states are the same. The response is to drop implementing the state machine as a state machine and resort to if/then statements to cover the state space. This approach has a chance of working especially if the original programmer adds some comments about what is expected from the statements and thus giving the next code visitor (the poor person debugging a problem) a hint at the logic.

If you transform the program from if/then procedural programming into a functional program, the state table doesn’t go away. It’s still there but is now embodied in the end nodes of the functional projection of the stream interactions. I mean, the relationship and movement between the states still has to be there but it is in a different form.

I see the state machine form and the functional programming form as two expressions of the same problem and solution. The question is which one affords the best adaptation to the input, the best execution implementation and the best vehicle for debugging.

For me, two of the advantages of functional programming are:

• better model of problems relating to flow of events
• better representation of the program for lazy evaluation and distribution.

The first point is about using a programming tool to easily express the desired solution and to easily debug any problems. For the state machine approach expressed above, say one forgot about an error condition. For a pure state machine implementation, the solution is to add some more states and actions. For an if/then implementation of the state space coverage, the solution is to add more if/than statements which often leads to spaghetti code and unexpectedly breaking things that used to work. The functional program version seems closer to the latter situation – a new error condition means adding .filter or .map to some transform to patch up the condition. Are there tools for finding the new conditions? Say there was a test suite that pushed values through the code. How would error conditions be found? Are there ASSERTs for functional code?

For the second point, computer languages have added features allowing the computer to do some jobs and thus relieving the programmer of some onerous task. Garbage collectors meant that programmers didn’t have to worry about memory allocation and deallocation. Lazy evaluation and distribution of closures means a programmer doesn’t need to worry about optimization of a stream of data transforms (usually done as some complex collapsing of multiple dissimilar transform operations) or the scheduling and placement of data and parallelizable computations.

But the infrastructure has to be able to implement lazy evaluation and distribution. Thomas Reynolds’ Functional Programming in Javascript Equals Garbage describes two problems with functional/reactive programming in JavaScript: 1) there are usually easier ways to accomplish the same in the language without all the new functional cruft, and 2) functionalizing is done in JavaScript with piles and piles of functions that do not know, for instance, how to collapse tail recursion and all the other lazy evaluation features of language implementations designed for functional programming.

After writing the above, I will go back and read The Reactive Manifesto and General Theory of Reactivity and think about how to apply this technology. I am not one to discount a New Thing just because “programmers have been doing this for years” or because this is just the Latest Thing. Tools and conventions are being developed that could make it a better solutions for some problems – a better solution than the way I’ve always done it.