30 August 2013

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?

Keep up to date with Simple-Talk

For more articles like this delivered fortnightly, sign up to the Simple-Talk newsletter

This post has been viewed 6175 times – thanks for reading.

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

Tony Davis

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page.

As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management.

In his spare time, he enjoys running, football, contemporary fiction and real ale.

View all articles by Tony Davis