From my analysis, most of the evidence points to visual programming languages actually being better. But.... there's just one problem, it's not plain text. The advantages of plain text are so powerful, and so pervasive, that they're like oxygen: We're so accustomed to them that it's hard to imagine a world without it, where we'd all be walking around without helmets on. Why is plain text so important? Well for starters it powers version control and cut and pasting to share code, which are the basis of collaboration, and collaboration is how we're able to construct such complex systems. So why then don't any of the other apps use plain text if it's so useful? Well 100% of those apps have already given up the advantages of plain text for tangential reasons, e.g., turning knobs on a synth, building a model, or editing a photo are all terrible tasks for plain text.
Once the task is to loop over time and do a bunch of processing, all the visual tools break down. They are two separate categories, two separate functions that shouldn't really be treated by the same tool just because they both use 'code'.
For example the visual programming languages for music and multimedia Max/MSP and Pure Data.
While you could use them to create a stable form, they are in my opinion much more useful and interesting for rapid prototyping, live coding, create or connect interactive systems, etc.
Sure, they are a bit niche, but certainly don't break down as soon as you loop over time and do a bunch of processing.
My meaning is more narrow I guess. Desktop apps and video games are built to run themselves post delivery. Music/film/3d models/textures end up as arranged bytes that are used as content for the apps and games to display. I guess textual programming languages work best when building the hierarchies and branches of loops that runtime apps have to self-navigate. Visual programming languages work well at symbolically representing many many many different rabbit holes one can draw from to produce an arranged set of bytes.
The visual stuff breaks down when you have to bake in navigating hierarchy after the product is out of your hands. The text stuff sucks at building 3d models vert-by-vert or with pattern matching. I haven't thought it all the way through.
As a wrote in another comment, where visual programming shines in my opinion is as a way to interact with an underlying complex system. An alternative to scripting languages.
To take the Max example further. Ableton Live integrated it deeply into their digital audio workstation. Although Ableton itself, not even talking about all the third party plugins, provides enough tools to make music with for a life time, having Max integrated opened up a whole new world of exploration beyond what the UIs created by the host and plugin vendors offer and it allowed non technical people to create and share their own extensions to a software.
I think even for trained programmers there is maybe more potential for visual programming. Maybe not for the core software we are writing, but to at the same time interact with and visualize the software and the ecosystem. I sometimes feel we are a bit stuck to have to either use cli and textual tools or graphical tools with limited and vendor specific UI.
I don't know how this would look like, since I'm a person that almost always defaults to cli and textual tools, because I know I can get the job done with them. But having used visual programming quite a bit outside of work, I'm intrigued to give it more attention to.
High-level iteration is less intuitive, eg. iterating over random seeds for a sim and rendering preview animations, but the process is still easier than switching the entire thing to text input. The toolkit for this is called PDG or TOP networks.
There are more examples. Some people have mentioned Matlab/Simulink. In fact, many procedures are defined using some kind of visual programming. For example, in CAD and modeling software (like SolidWorks), you have a tree of operations that is just a visual program. The way in which effects are handled in PowerPoint is visual programming too. Even it could be argued that, when playing a game, you are just doing visual programming.
Because it's inefficient as hell. That may be mostly a problem with existing tooling, but it is a problem.
For context, I'm currently doing a side project with Unreal Engine 4, which uses visual programming for scripting and defining shaders; I'm sticking strictly to these tools, because I can't be arsed to set up yet another C++ dev environment on yet another machine. Because of that, the pros and cons of visual programming are on the top of my mind right now. Here are some thoughts:
Visual programming is fun while you assemble high-level blocks together. But god forbid, you have to do any maths. You end up spending 10 minutes assembling an unreadable mess of additions, multiplications, LERPs, etc. taking half of your screen, to build an equivalent of three lines of code you would've typed in 30 seconds in your editor.
(This presents an opportunity for improvement: why not give a generic "math" node, where I could just type a math expression by hand, and have the free variables show up as input pins? There's really no point in assembling things like "lerp(A x B, C x D, alpha) * -beta" from half a dozen nodes.)
(EDIT: turns out this exists in UE4, see https://news.ycombinator.com/item?id=23256317. I learned about it just now.)
In general, all the dragging quickly becomes annoying. As a trained programmer, you can type faster than you can move your mouse around. You have an algorithm clear in your head, but by the time you've assembled it half-way on the screen, you already want to give up and go do something else.
Visual programming is fun while your program fits on the screen. Because of the graphical representation, you'll usually fit much less code this way than you would in text. This, plus the fact that anything nontrivial won't form a planar graph (i.e. edges will have to cross somewhere), makes you want to abstract your code hard, otherwise it gets impossible to read. And here is where Unreal Engine starts to fail you. Yes, you can make perfectly fine functions - which are their own little subgraphs. But that also means they're different "tabs"; it's hard to see the code using a function and the code of a function simultaneously on the screen, it's hard to dig in and back out, jump around the references.
As an improvement in that particular case, I'd love if I could expend individual blocks into their definitions "inline", as a popup semi-transparent overlay, or something that otherwise pushes other nodes out while still keeping them on the same sheet. But given the performance of the editor, that would just burn my CPU down.
I think visual programming works well for artists, because when building shaders, you mostly stay on a single level of abstraction - so a flowsheet you can zoom around makes sense. But when you start coding logic and have to start DRYing code, dividing it up into layers of abstraction, the ergonomics starts to wear you down. Then again, I hear good things about LabVIEW, so maybe it can be made to work.
Where I think visual programming shines is, as a way to interact with an underlying complex system, like the artists you mention. As and intermediate step between a rigid and often limiting classical user interface (forms, knobs, buttons) that someone needs to define and implement and the "real" code.
And I think trained programmers as well can have use cases for this. For example ETL tasks, continuous integration, etc. For me the important part is, that there is an escape hatch, and I can drop down to writing code if the blocks get in the way.
Meh, I've worked on two games made in Snowdrop, where pretty much most of the game logic is made directly in the editor, all of the shaders, all of the animations, all of the UI is made using a visual scripting language and it's been more than fine. It meant that we had people who didn't know much about programming "coding" entire logic for animations for instance.
>>You end up spending 10 minutes assembling an unreadable mess of additions, multiplications, LERPs, etc. taking half of your screen, to build an equivalent of three lines of code you would've typed in 30 seconds in your editor.
Yes, which I appreciate is frustrating if you actually know how to type those 3 lines of code, and where to type them and how to compile the project and run it from scratch(so on the projects I worked with yes, it would take you 30 seconds to type in the code, but then 10 minutes to build and another 10 to run the game, while making those changes in the editor-based visual script you'd see the changes instantly). Our UI artists for example never even had Visual Studio installed and in fact I don't think they even synced code since they never had to - visual scripting was such a powerful tool for them that there was no need.
That's orthogonal to visual programming, and just the symptom of most programming languages being edit-compile-run. Compare that with UE4 (as far as I know) not allowing you to modify blueprints in a running game. Contrast that with different programming languages. I do some hobby gamedev in Common Lisp from time to time, which is a proper REPL-driven language. There, I can change any piece of the code, and with a single keystroke in my editor, compile it and replace it on a living, running instance of my game.
I don't know whether a spreadsheet counts as "visual programming", but they are a much more accessible way for non-programmers to manage mathematical concepts.
Indeed, spreadsheets can be thought of as a kind of visual functional programming.