Most data flow programming environments cannot represent lambdas, and this is why the graphs always end up turning into spaghetti: you don't actually have tools to reduce repetition in the graph's structure, using the graph itself.They are successful in artist and music contexts because the graphs tend to be simple pipelines at heart. Having dealt with sufficiently complex grasshopper graphs, I disagree that it's good at arbitrary list processing, certainly compared to ordinary list operators and iterators in code.My conclusion is that a dataflow environment that does allow for lambdas and proper n-way forking would necessarily have to be an effect system in the FP sense. It's a data flow graph that computes its own continuation and which has no fixed or preset topology. It can rewire itself based on the data flowing through it.

Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.Visualize data, not code. Dynamic behavior, not static structure.”http://worrydream.com/#!/LearnableProgramming