Anthony Eden speculates some more about Visual Programming:

As mentioned in my last post I think that the problem with the visual tools today is that they are using UML to express something which can be expressed with the same ease in a text language with no advantage derived from the visual representation. It will take a tool which focuses on interaction between components at a much higher level in order to truly take advantage of visual programming. And while workflow orchestration tools head somewhat in this direction I believe that there we are still not tackling the problem in the appropriate fashion.

What bothers me about the post is that there's nothing concrete, its like Sci-Fi.  Its like saying all the problems of this world will be solved if we become a society like that found in Star Trek.  A society where there's no money, but everyone is motivated.  What I would really like to know is how to get there? 

So, here's my vision.  To start with, the goal is not visual programming, rather the goal is to provide better programming tools.  All this talk about augmented reality and programming with multiple senses is IMHO a bunch of crap.  My take has been that the textual form is the most expressive form and visualizations are used to augment the text.  I take this inspiration from how Eclipse does its stuff. In fact, Together takes the same approach, and that explains why its so good at roundtripping, that's because there's only one source.

However, anthony talks about "interaction at a much higher level".   First, I disagree with his statement that UML doesn't express anything different from the text.  That's plain wrong.  State diagrams for example express facts that may actually be implicit in the code.  In the case were the tool is able to generate code from State diagrams then the facts are explicit in the text.  Therefore, to be able to create any view of code, the constructs should be explicit in the text.  This is a fact simply because its beyond today's technology to derive knowledge from code that is implicit.

Therefore, its necessary for programming constructs to be explicit so that a program can recognize, reason and then render them.  This also explains why functional programs are easier for programs to reason about. This is because state for functional programs are explicit, unlike imperative programs where state is actually implicit (Actually there's no state for functional programming, its usually simulated in functional form).  

The methodology goes as follows, build high level programming constructs using the base language.  Create visualizations of these higher level constructs.  That's how you get from point A to B.