NoFlo is a flow-oriented language build using JavaScript that is causing a small media sensation. The report that it has raised half of its $100,000 target in just a few days has attracted a lot of attention. Is this the dawn of a new era in computing? Is this the future of programming?

Probably not. 

NoFlo is a language plus a GUI editor and it is the GUI editor which is getting the most attention. It promises to make programming easier and far less technical by allowing the programmer to hook up components. The idea is that the data flows from component to component and the graph of components and lines determines how it flows. 

Flow programming was invented in the early 1970s, yes there is nothing new under the sun, back in the days when Fortran and Cobol were the dominant languages. The idea that you use a flow graph to build programs isn't a huge leap of imagination as programs have a natural graph like structure. This is why we used flow diagrams and still draw all sorts of graphs on whiteboards that show how our programs work. The idea of flow programming, and NoFlo in particular, is to attempt to convert the effort of drawing a graph into the realization of the program.

Nice idea, and it is claimed that the approach has some additional good properties like scalability and a natural tendency not to produce spaghetti systems. As the Kickstarter pitch puts it:

"Software begins as boxes & arrows on a whiteboard, let’s keep it that way! Imagine, a platform that eliminates spaghetti code..."

The Kickstarter is to raise money to meet a ragbag of objectives, but the main one is the development of a drag-and-drop UI for the language. The UI will convert the graph into JavaScript that runs on either Node.js or in the browser. There are some stretch goals that include a Java implementation to build Android apps and a version generating iOS apps in Objective C.

Currently NoFlo is mainly a Domain Specific Language (DSL) for connecting components. For example:

• 'somedata' -> PORT Process(Component) sends initial data somedata to port PORT of process Process that runs componentComponent
• A(Component1) X -> Y B(Component2) sets up a connection between port X of process A that runs component Component1 and port Y of process B that runs component Component2

There is also a JSON format that can be used to describe a graph with connections like the ones described above. If you look over the documentation you have to come to the conclusion that it is all very simple. 

It all sounds great and the promo promises much and, let's be honest, we all feel that there has to be a better way to program than what we are doing at the moment.

So is NoFlo the promised land?

The idea of connecting components together has a longer history than just flow programming. You can think of the pipe command in Unix as being a rudimentary way of hooking up programs. Back in the very early days of programming Michael Jackson noticed that algorithms tend to follow the form of the data - if there is a repeating element in the data then you need a loop to process it in code. The Jackson method was probably the most hopeful method of automating programming until object-oriented programming came along.  Systems like BizTalk, LabView and so on all make use of connecting components together, but nothing has made the transition to general-purpose programming.

The trap is that while you are thinking about particular problems it is easy to see how to build a system that automates the programming task, but then along comes someone with a different class of problem and your attempts seems limited.  In this case we are looking at something slightly different. NoFlo is a way to hook up components. and the components are written in JavaScript. What this means is that you can always use the system to solve a problem - because you can write a single component that solves it with a single "problem in, solution out" data flow. Of course this isn't very useful and the hope is that real world problems can be broken down in to smaller components and then hooked up with NoFlo "wiring". But it is obvious that NoFlo is simply providing the higher level architecture - the real work is still being done by hand-coded JavaScript (actually CoffeeScript classes):

"NoFlo components react to incoming messages, or packets. When a component receives packets in its input ports it performs a predefined operation, and sends its result out as a packet to its output ports. There is no shared state, and the only way to communicate between components is by sending packets."

This might, however, be enough to make it worthwhile but it is a mistake to assume that graphical methods are incapable of producing spaghetti. As long as the system is simple then the graph seems simple, but if it has many components it degenerates into what looks like a ball of spaghetti. As with all implementation schemes, without an ability to build hierarchies of levels, spaghetti is inevitable - even if it is relatively ordered spaghetti. 

The real problem with NoFlo is that it is just thinking on too small a scale. We already have graphical methods to work with components and build detailed algorithms at the micro-level. Take a look at Scratch or AppBuilder or any of the other existing graphical languages. Take one of these as your starting point and you might have something new. 

We need graphical tools, and just better tools in general, to build programs but NoFlo is just one possibility and not a very innovative one - I for one can't really understand why it is getting so much attention.