Pretty much. One ideal might be for a flow chart to come alive and actually be the structure of your application itself, rather than just a reference or an aid.

I suppose that while visual programming excels at conveying topology and structure, it can be weak at a low level due to the tedium involved. Traditional code is arguably better suited for low-level grunt work, at least for most people.

A hybrid solution might be best. For example: a message travels from one high-level visual entity to another, and you'd easily be able to drill down into the code comprising those entities, locating the exact lines responsible for emission or receipt.

This is the most famous big attempt for visual approach up to now (first time standardized 1997), and the recent (2013) results are:

http://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf

"Even if UML is viewed as the ‘de facto’ standard, it is by no means universally adopted. The majority of those interviewed simply do not use UML, and those who do use it tend to do so selectively and often informally."

"They also highlight some of the fundamental tensions within UML, resonating with arguments [8], [25], [17] that UML’s intended strengths (i.e., generality, accommodating different levels of abstraction) are intimately associated with its observed weaknesses (e.g., latent complexity, issues of transformation and coordination between views) and arise from fundamental properties of UML (e.g. lack of formal semantics, separation of expressions of structure and behavior)."

Whatever we do next, we have a nice set of examples and case studies of "what can go wrong."

The specific software tools based on UML are especially good examples of the problems.

While I'm not terribly familiar with UML, I was under the impression that it's primarily a modeling language, not necessarily a visual programming implement.

As far as I'm aware, most visual programming today is actually implemented in the form of node-based editors, which gained popularity in the film and visual effects industries well over a decade ago.

The best modern examples I can think of are probably Nuke[0] and UE4's Blueprint[1] system.

[0] https://www.thefoundry.co.uk/products/nuke/

[1] https://docs.unrealengine.com/latest/INT/Engine/Blueprints/E...

I've tried this, some two decades ago:

https://en.wikipedia.org/wiki/Rational_Software

"The development of Rose 2.0 combined a Windows-based Booch notation editor called Object System Designer (acquired from Wisconsin-based Palladio) with a new intermediate representation, and with new semantic analysis, code generation, and reverse engineering capabilities. The latter, which allowed prospective customers to analyze existing C++ code to produce "as-built" navigable class diagrams, helped overcome Rational's late re-entry into the market for object-oriented modeling tools. Rose 2.0 ran on Windows PCs and on several Unix-based workstations."

It wasn't usable, except to be used in the projects doomed to fail. Or spend a lot of money. Which is something a goal of the managers. But it still can't be named a success.

Author here. Thanks for the discussion.

UML didn't pick up for whatever reason and visual programming fell into the valley of deception. I expect that with more UI/UX research we can get to the plateau of productivity in the next decade.

Btw, there is a variant of UML that is executable. https://en.wikipedia.org/wiki/Executable_UML

Wrong. Here is a thing, soviet spaceship Buran, which was performing fully automated landing in 1991, was programmed with this stuff - https://en.wikipedia.org/wiki/DRAKON. Teams of software engineers created this language so rocker scientists would be able to programm spaceship without software developers.

> there is a variant of UML that is executable.

If you believe it's a good way, you should certainly go that way. Please write about your experiences afterwards.

Rose 2.0, I've mentioned and quoted explicitly, produced the code from the diagrams (that's the "code generation" from the quote). And it was tragedy. Maybe you find somebody's experiences on the web.

"And it was tragedy."

That sounds quite positive compared to my experiences with code generated from UML.

I don't have a problem with generating diagrams from configuration and/or code (e.g. with Graphviz) but I'm not keen on diagrams actually being edited and used to generate stuff. However, I would say that my aversion isn't based on a fundamental problem just on my experience that "graphical" tools are often awful from a usability and practicality perspective so that the benefits never seem to clearly outweigh the significant issues (e.g. compare diffs of text files with diffs of diagrams).

>However, I would say that my aversion isn't based on a fundamental problem just on my experience that "graphical" tools are often awful from a usability and practicality perspective ...

Yeah. For any truly novel visual programming approach to succeed it'd probably require some next-level UI/UX work for sure.

author here. Thanks for the comments!

Visual programming could be very well an alternative. Or fucking oculus vr or god knows why. I 100% agree with rl3, it proposes a very interesting and challenging problems for the UI/UX folks.

You might want to look at https://en.wikipedia.org/wiki/DRAKON. Teams of soviet software engineers created this language in 1980-s so rocket scientists would be able to program spaceship without software developers. Buran was programmed to perform automatic landing using this.

Labview has some interesting ideas (I think a subset made it into Lego Mindstorm)

Also many people don't use what is available to them. Modern IDEs support single-stepping and painless runtime introspection, and many have supported it for 20 years.

Still people resort to trying to trace out in their head what happens runtime.