How do you talk about them? How do you write about them?
It may well be solvable - I'd like it to be, I spent a couple of years of my spare time toying with visual languages, and I still think as an idea there is a lot of potential. But you need a notation that can be read out in a way that makes semantic sense, the way mathematical notation (despite my very many reservations about mathematical notations) can. And mathematical notation is a good example of all the problems it brings in terms of tool support to even ensure you can reliably typeset it without having to include images of it.
I think it's more likely that we'll see improved interfaces to decorate or explore a textual code-base better, though, possibly with some languages starting to be designed with such tools and representations in mind if/when we start to see something closer to a standard emerge.
in general it is harder to build tools for graphical languages, I think this has been prohibitive. parser are hard, but diagrams require constraint solvers and what not, on top of the parsing.
but we came a long way since 1990, both on our actual abilities to build the stuff (JS and the browser can do powerful visual things) but we also understand functional programming and it's relation to mathematics much better.
anyway, thanks for your comments! Nice thread and you are 100% right with the TODO list; we actually build a tool (here is a basic pre-version https://github.com/wires/roadmap-viewer) to manage the intricate roadmap needed for this big project. Stay tuned! :-)
For example, GC was conceived in the 1950's, and through at least the late 1990's it hadn't taken off "in a more mainstream way", and people were saying "this idea comes back around every few years" as evidence that it never would. It turns out that GC is actually a pretty good idea, but the average computer prior to 2000 or so wasn't so good at it, either in hardware or software. That didn't make it a bad idea. It was a good idea that we weren't yet great at implementing.
What I'm hearing about visual programming today sounds very similar. Everyone has a list of complaints, but they're very specific, and very fixable. No good editors -- agreed! The solution, then, is to write a good editor, not to throw out all of visual programming. (Remember what the machine language programmers said about compilers, back before we had decent text editors?) No good diff tools -- agreed! But once upon a time, text didn't have good diff tools, either, so we wrote them. And so on.
If you start with the premise that visual programming is bad, then you will see a list of 10 problems as evidence that it's insurmountable. If you start with the premise that visual programming is good, then a list of 10 problems is your TODO list for the next year.