Flow charts are not a programming language, largely because they are two dimensional and pictorial, and there is no convenient way of reading them into the computer. This situation will almost certainly change, since graphical input devices using large cathode ray tubes are now being developed for computers; but for the present, flow charts are limited to expressing algorithms.
Having implemented, as part of my master's thesis, a program which would turn charts into code, and having since had the pleasure of working with several other ill conceived software products along the same line, I can only agree with Brooks. It hardly scales beyond the "Hello World" example which sold the idea to management. The only way to salvage anything from such a project is to commit any generated code of value and clean it up until it's maintainable.
i really like scratch, have started using this tool called pibakery that has a similar block-based interface: http://www.pibakery.org/
If nothing else, visual programming is of educational value
etc:
Seymour Papert's Logo maybe fits in somewhere here (source of turtle graphics)
sketchpad: https://www.youtube.com/watch?v=495nCzxM9PI
That being said, I think there may be a niche for visual programming tools when developing visual stuff. I'm old enough to remember Delphi, and also I made a few games in Flash back in the day. In both cases you would arrange visual elements, and you would attach stuff like event handlers written in a "real" programming language. I think the reason that it worked was that the visual part would be describing structure, not algorithms. In the same way that HTML is pretty good for describing UI elements without pretending to be a full fledged programming language. I'm not sure this division of labor would apply to Unity as well but I would presume so since it makes a lot of sense.
As for Scratch, I see it more as a real programming language but with a visual editor that makes it easy for beginners to compose programs by dragging and dropping. I think the tradeoff is great for beginners: makes the constructs visible and avoids syntax errors. I don't think it would scale to large projects, but that was never the point.
BTW, remember Logo from my school in the 1980s. I even seem to remember that we had the real, physical turtle at some point, able to draw lines on a sheet of paper. Or maybe my memory is deceiving me.
It seems the only "visual programming" environments are either domain-specific, esoteric, intended for children, or some combination of the above. And I think that's a damn shame. I'm a data scientist, not a computer scientist: give me a suitable abstraction layer on top of code, and I will use it. I think flowchart-based programming is one way, maybe the only way, to make this possible.
Nowadays I do think that visual programming is better for domain-specific purposes. I also think that for many purposes code is a suitable abstraction layer on top of machine instructions. Meanwhile abstraction means removing nonessential detail, however for a general purpose programming language one cannot predict which features are essential in a specific application. That's why visual programming is working in domain-specific areas, because in that case you can often decide which details are nonessential.
Now, certainly the specific failings of WF, and the bast^H^H^H^H person who wrote the tool were partially to blame here, but even with all that in mind, the experience has permanently soured me on visual programming. It has all kinds of flaws-- it's harder to reason about, harder to debug, harder to comment, and harder to quickly modify that plain old source code. If there was some trade-off, an upside for all that trouble, maybe it would be worth it, but I can't see one.
Of course, a GUI's performance would highly depend on its user experience. I wonder how an existing graph manipulation program like Gephi might fare, versus something specifically optimized for this task.
But I badly want it for bigger, architectural concerns. Why do our IDEs just display lists of files in a pane? I've often day dreamed about an IDE where the system is visually modeled as a network of modules/objects, with edges representing dependencies, and you'd double click on a module/object to edit its source code.
Somewhat relevant: http://prog21.dadgum.com/69.html
A unix command line gives me a similar feeling with processes feeding their output into other processes each doing some kind of transformation on their input with the | character functioning as the lines in a flowchart.
Now obviously that has some differences with an actual flowchart (such as 'if' statements) but the effect is close enough that there are some parallels.
It's a graphical programming language, you connect wires between modules and operators.
Its weird to get used to at first, especially if youre proficient in text-based programming languages, but when you get a feel for letting the program flow drive the logic, you can do some pretty powerful things.
The general idea is that you have a "front panel" that controls user input, and then the back-end programming. Eg, Boolean inputs can be a variety of switches, outputs can be lights and LED's. Floating inputs can be knobs and sliders, outputs can be displays, meters, bar graphs. Very easy to add plots that update in real time.
It's popular with lab research and data acquisition users, since you can easily whip up nice UI's, and many producers of laboratory hardware provide LabVIEW drivers.
You can also easily create advanced techniques or data structures too. Eg, wrap a state machine inside a queue widget, for a "Queued State Machine".
Some drawbacks are that it's proprietary commercial software, and the 'code' can easily become a tangled mess of wires.
Example implementation of a state machine : http://www.ni.com/tutorial/7595/en/
The big problem I see with visual programming tools though is that they prescribe the tools you can use to work on the system. I can work on the same Python scripts on Windows, Unix and iOS, in a windowing environment or a console. I can use Submlime Text, Vi, EMACS, Notepad++, whatever I want and configure them however I like. Syntax highlighting even visually distinguishes different aspects of the code in useful ways that even parallels some of the features of graphical coding environments. I can even generate code from other code, or use refactoring tools.
If your graphical tool generates text or something like XML then ok, you can do processing on that, but which is authoritative? The graphical representation or the underlying document? Now all you have is a fancy editor for what's really a text format anyway.
So I think in a lot of ways visual tools complicate things in some ways as much or more than they simplify them in others. I suspect that the domains in which these trade offs prove to be worthwhile are fairly limited.