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..."
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.
"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.