Has Flow-Based Programming's Time Arrived? 268
An anonymous reader writes "Flow-based programming keeps resurfacing lately. FBP claims to make it easier for non-programmers to build applications by stringing together transformations built by expert programmers. Many projects have already been using similar approaches for a long time, with less (or different?) hype. Is it time to take a closer look at flow-based programming? 'Clean functions – functions without side effects – are effectively pure transformations. Something comes in, something goes out, and the results should be predictable. Functions that create side effects or rely on additional inputs (say, from a database) are more complicated to model, but it’s easier to train programmers to notice that complexity when it’s considered unusual. The difficulty, of course, is that decomposing programs into genuinely independent components in a fine-grained way is difficult. Many programmers have to re-orient themselves from orthodox object-oriented development, and shift to a world in which data structures are transparent but the behavior – the transformation – is not.'"
Re:Isn't this just... programming? (Score:4, Interesting)
When you look at a C or Java program, when you're looking through the source code, the main thing that is presented to your eyes is the actual algorithm, the code that is doing the work. Sometimes you have to do a lot of effort to even figure out where a program starts. A good class diagram can capture a lot of that, but usually there is still a lot missing in class diagrams. So you might say those languages are algorithm based or something.
With flow based programming, when you look at a program, the first thing, and most obvious thing you see is the connections between modules; the way control and data are passed around the system is obvious. But you have to do extra work if you want to look inside the 'black box' modules that are actually doing the work.
With apologies to Dijkstra, one might say that Flow Based programming is an exceptionally bad idea which could have only originated at IBM (in my mind the division of labor between those who are making the 'black boxes' and those who are connecting them together is extremely difficult to get right), but the idea of making the connections between modules more obvious is definitely a good one. I hate looking at new codebases sometimes for exactly the reason that it's hard to see how the modules are put together.
A.k.a shell scripts (Score:5, Interesting)
grep EVENT log*.txt | sort | uniq | awk '{print $2}' | ssh reportserver "gzip > results.txt.gz"
Flow based, side effect free, distributed computing on one line. There is a reason shell scripts refuse to die in the face of python, perl or anything else.