Going with the Flow

Every so often, a new programming model or framework emerges, promising to tackle the burgeoning complexity of the software development process. This week, the potential savior of the sanity of web developers everywhere is an “Arcane Coding Method from 1970s Banking Software“. The arcane method in question is Flow-based Programming (FBP) and, at its core, the piece aims to promote a new framework called NoFlo, an implementation of FBP for Node.js, which allows the programmer to construct their data flow logic by connecting components in a visual, network-style diagram.

To call FBP arcane is a bit unfair. FBP never went away. The ideas became part of the established conventions of multitasking event-driven asynchronous systems. However, it didn’t take over the mainstream from the more intuitive, brute-force method of problem solving via procedural languages.

Any attempt to simplify and visualize the software architecture and design process is laudable, but I doubt that FBP is, as the author suggests, a “revolution still waiting to happen”. It is certainly a good way of tackling a specific range of problems but is it a general solution? Fred Brooks set out most of the reasons it hasn’t, and probably won’t, gain mainstream support in his No Silver Bullets paper. Firstly, visual/graphical programming attacks only the accidental complexity that creeps into many projects, not the essential complexity of the problem. Can the visual approach really make the design process accessible to the input of non-programmers? As complexity increases, so the “slide towards an unreadable spider web of lines and hundreds of boxes” will deter even the most dogged.

Likewise, data flow programming itself doesn’t really attack the intrinsic complexity of the process being automated. It only changes the way we express the problem. However, it is attractive because it gives clarity to the nature of the process and the current state of each instance of it. It can control the flow of data between components. This helps with the tricky requirements of tracking state in parallel processing. In dataflow programming, we define data declaratively rather than writing procedural code and we need look no further than Excel to understand the potential power of this approach. Having defined the relationships between the various cells, tasks proceed with no need to control how and when certain data values update in response to other changes. Various libraries already allow us to incorporate elements of dataflow programming into our existing languages (for example, Underscore.js and Knockout.js brings declarative data binding to JavaScript).

Database developers have lived happily in a strange non-procedural, multithreaded alternative universe that can baffle the procedural programmer. Could it be that the rise in popularity of event-driven platforms like Node.js, and asynchronous I/O, might yet jolt procedural programming from its current dominance amongst application programmers? I’d welcome that. Would you?


  • Rate
    [Total: 0    Average: 0/5]