I think there is some broad confusion over "flow-based programming" implying "non-programmers using a graph editor to connect things". So I'm going to ignore th

I think there is some broad confusion over "flow-based programming" implying "non-programmers using a graph editor to connect things". So I'm going to ignore that completely in favor of talking about flow-based programming for programmers. Here's an example I have experience with: The GRL research language [1] is a dataflow language for behavior-based robotics. It's a real programming language that batch compiles down to C code that runs in O(1) time and space (it's not Turing complete). It escapes from the "spaghetti code" problem you mention by providing an abstraction of a procedure as a compile-time rewrite rule that transforms the dataflow graph (for Lisp hackers, every procedure is basically a macro that can be passed around by value at compile-time). (FWIW, graphical editors can actually be a useful and pleasant way to construct throwaway flow graphs, but aren't particularly useful for developing new abstractions (i.e. dataflow procedures or data types). They run into the spaghetti code problem you mention, by which the only way to reuse a chunk of functionality is copy-paste) The system has been used for things like programming actual robots, Half Life bots [2], and motor control for interactive game-like thingies [3]. What it's really great at is managing stateful information over time. Things like moving averages, low pass filters, and other types of state machines (flip-flops, "just true" constructs, etc) all become first-class values in your programming language. So how could this be used in a more flexible environment that isn't ideological about dataflow programming? While dataflow graphs may be limited in their expressiveness, we can use them to encapsulate many types of state machines, particularly those that change over time or in response to stimulus. Under this model, every self-contained flow graph becomes a thunk whose input values are determined by evaluating arbitrary expressions in the host language (and can be dynamically instantiated). For implementations of this technique, see [3]. Finally, [4] is an implementation of the stateful time-based dataflow constructs I wrote for a game in C#, which power things like motor behaviors, input processing, collision avoidance, animations, and interpolations. As a bonus, you can add events on top of these for a simple implementation of functional reactive programming. So do you want to build a web app in a dataflow language? Maybe not. Do you want flow-based constructs in your programming language? Depending on what you're building, the answer could range of "Not really" to "I can't live without them." [1] http://www.cs.northwestern.edu/~ian/grl-paper.pdf http://www.cs.northwestern.edu/~ian/grl-paper.pdf [2] http://www.cs.northwestern.edu/~gdunham/flexbot/manual/grl_for_flexbot.htm http://www.cs.northwestern.edu/~gdunham/flexbot/manual/grl_f... [3] http://www.aaai.org/ocs/index.php/AIIDE/AIIDE11/paper/view/4081 http://www.aaai.org/ocs/index.php/AIIDE/AIIDE11/paper/view/4... [4] https://bitbucket.org/leifaffles/chad/src/d6a13c2315cce41dba1b4572749bd3969c821286/ChadEngine/Signals/Library/Stateful.cs https://bitbucket.org/leifaffles/chad/src/d6a13c2315cce41dba...