Been thinking about visual programming languages (UE4 Blueprints, Scratch, etc) and have come to some realizations about why I'm not happy with any current approach. Thread...
Visual languages come in two major flavors; "blocks" and "boxes and wires." Blocks attempt to be a direct analog to the structure of textual code, while the wire approach aims to depict a program's actual flow. However, each has flaws. 
Wires sound great at first, but once you start building something even mildly complex you begin to see the literal manifestation of "spaghetti code." Where does this code start? What does it do? Like regex, it quickly becomes a one-way operation; write-only
Better structure can help, but even then, the problem is a bit more inherent. Part of the problem is expressions, no matter how simple, become sprawling as they each get dissected into their components that could otherwise have been very readable inline
One has to ask, what is the value of visualizing expressions as data flows? One area where this has seen success is in visual authoring tools like substance designer and shader/material graphs such as Substance Designer, Shaderforge and even UE4 Material graphs.
These are successful because, unlike general purpose languages, the entirety of the program is essentially a giant expression and you need the ability to preview each step. There's no execution flows or state management to worry about. But these still don't avoid spaghetti...
The other part of the problem is these graphs are lying to you. There is no true code-analog to some of the structures they depict and consequently are misleading you into bad habits. Let me explain...
Consider this graph: We multiply foo and bar, and if the condition is true we return it, if false, we multiply by -1 and return it. We're referencing the same naked expression in two places without turning it into a function or saving it to var. This isn't how code works.
As an aside, also note how the execution flow (white lines) are completely independent from the expression flows. Often this can get very confusing.
Here are three ways you can write it that graph. None of these are a literal translation of the graph, so unreal picks one (probably in-lining). By giving you the ability to refer to naked expressions, graphs trick you into bad coding habits in the name of false efficiency.
The vast majority of "spaghetti code" in graphs stem from this one issue. If you want to take a look at this in action, check out blueprintsfromhell.tumblr.com and see how often single nodes branch off to many vastly distant parts of the program
So what about the block-based approach? expressions are easy to read as it mirrors how we write math, but so does text-based languages. One has to wonder what benefit is this approach really providing beyond avoiding syntax anxiety. remove the fancy colors, it's just code
So where do we go from here? I think there's opportunity for a new form of visual programming that takes the best parts of both. Flow graphs are objectively useful for understanding how our code works, but it's being bogged down by trying to also represent expressions as flow
And blocks are genuinely useful for visually describing expressions, but don't aid the understanding of program flow. I have a strong feeling a language that uses blocks for expressions, and uses wires for execution flow could be the solution.
