Clunky compared to what? Other visual dataflow languages (Prograph and LabVIEW) use additional constructs for iteration and conditionals, complicating their s

Clunky compared to what? Other visual dataflow languages (Prograph and LabVIEW) use additional constructs for iteration and conditionals, complicating their syntax. The original plan (as described in the papers) required several different emitters and collectors. Allowing edges to loop back for iteration would complicate the editor. TAnother option is tail call elimination, which forces you to think recursively about something which is naturally iterative. If you can think of something better, I'd be interested to know what it is. Remember, there is no flow of control. Text-based languages have a different problem: indicating which parts of your code can be run in concurrently. They evolved to run on single processors, with flow of control specified by the programmer. The result is that programmers of those languages tend to think sequentially. Adding support for SIMD parallelismmight be straightforward, but MIMD parallelism is more problematic. With dataflow programs, you don't have to specify what can run in parallel. You also get homoiconicity for free: programs are directed graphs, the most general data structure. No parsing or optimization is necessary. Algorithms are reduced to their most basic form (actions and communication), not shoe-horned onto a von-Neumann computer architecture. This does, however, require the dataflow programmer to think in a different way. The typo has been fixed. Thanks for pointing it out.