Slashdot Mirror
Has Flow-Based Programming's Time Arrived?
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.'"
The basic problem is that, while it sounds great in theory, in practice the transformations you want don't exist. If they did, you'd have software doing the job already and you wouldn't need to create it. Your business isn't going to go very far just doing the same thing everybody else is doing, is it? You need to be doing something they aren't. Which means, in this context, you need transformations that don't already exist (either because they haven't been written yet (ideally) or because the people who wrote them are keeping them confidential to keep you from copying what their business is doing (less than ideal)). So on top of your FBP team stringing components together, you're still going to need that expensive conventional development team to write the components for the FBP team to string together. You haven't saved much, in fact it's probably costing you more than just having the conventional dev team.
Plus, stringing components together isn't quite as simple as it sounds. Real-world systems usually depend on interaction and complex relationships between otherwise simple components. Keeping track of the synchronization between all those parts and keeping everything coordinated is usually the hard part. For instance, when creating an application to set up appointments the part where you take a set of existing appointment slots (some occupied, some free) and a set of one or more slots the customer would like ordered by preference and determine the best requested slot to put them in is easy. Picking up the current set of slots, putting them up on a Web page in a sensible way, letting the user select what ones work for them and set the order of preference, sending that information back to the server and, across this whole process, making sure that either nobody could alter the assigned appointments between the time you picked them up to display and the time the customer hit Submit and you started to sort out the assignment, that's nowhere near as simple. Doing this in a modern system with multiple servers where the submission may not go back to the server that handled the initial request, when you've got thousands of customers and hundreds of your users making, changing and cancelling appointments at the same time, ... can we say "highly non-trivial"? And it really doesn't fit the FBP model at all.
Even where things fit the model, it's rarely as simple as "just string them together". I work with software that fits that model. Well, it did. Once. Long ago. And then the business people said "Oh, but customer A wants it do to some other thing if it's a transaction for them.". Followed by "Well, we want to do X, unless C applies in which case we want to do Y.". "Oh, unless M was specified for the account, in which case do X even when C applies except where X set V to 7 we need it set to 14.". Lather rinse repeat for 10 years and the quick one-line summary version ran to 5 pages single-spaced. Until that is we tried to print it out and found things were nested so deep some lines were starting past the right-hand edge of standard letter paper, so it's more like 10 pages, legal-sized, in landscape mode.