The best part is that there are actual working systems now.

It's been the case for decades.

Literally before PARC had their Alto nailed down, there have been visual programming languages where you draw and connect boxes in order to program.

And you should think really hard why (for the most part) we don't program this way today. It's not because we're just stubborn.

BTW, there are actual flying cars too.

I agree that "draw and connect boxes" is an awful interface for general programming. But I've used it and it's terrific for some data manipulation tasks; and there are other visual paradigms that are not based on Boxes and Arrows (such as UML/model-based architectures, visual constraints, "Programming on Principle", whole-execution "rewindable" debuggers...) that offer substantial benefits even for some more general - so there's people who ''do'' program this way, and find it better in some scenarios.

The idea is that, as computers are more powerful and can support visual tools that were impractical in the 80's and 90's, more programming styles can be created that aren't based on "one-dimensional stream of characters". Heck, even syntax highlighting and Python's "significant indentation" provide visual usability advantages over earlier language approaches. There's nothing inherently superior in the sticking to the old ways other than "it has always been that way".

The computers were strong enough to make visual tools possible even 20 years ago. It's the clumsiness and the limited expressiveness of interaction that limited the acceptance. I know: I was there. I remember reading Stroustrup who around the beginning of C++ wrote something like "we don't have to worry about ineffectiveness of headers in C++ because we'll anyway use visual tools soon." There were actually some tools. (http://en.wikipedia.org/wiki/Rational_Software "Rose 1.0 was introduced at OOPSLA in 1992") They stunk: http://c2.com/cgi/wiki?RationalRose

However, IDEs are alive and well, and browser DOM is stronger than ever - with "build your app" tools around each corner.

I doubted to put UML in there precisely because of Rational Rose and because UML didn't finally work as the basis for software architecture, but in the end that's still just a glorified C++ code generator - not an execution environment. Of course when your visual tool is a front-end on top of a traditional code it will have problems - you'll need a language that is designed from the ground up to work in a visual environment. And part of the reason why "visual environments" weren't created 20 years ago is because you couldn't execute the final program in visual form, in real time.

End-User development tools (rule-based like Agentsheet, graph-based like NoFlo or Blender graph editor, or even those based in traditional programming like Alice, Scratch or Code Combat) can be quite successful.