Somehow these visual programming tools never seem to get much traction.<p>Are there any exceptions?
Houdini (VFX/3D tool), virtually unchallenged in some of its domains, it's basically visual programming. Very basic what you'd do inside of Houdini when working with it (with screenshots): <a href="https://www.sidefx.com/docs/houdini/basics/intro.html" rel="nofollow">https://www.sidefx.com/docs/houdini/basics/intro.html</a><p>Unreal Engine also have "Blueprints" for game logic that remains fairly popular, maybe not always as the underlying systems, but at least as a control surface for game designers, like a "API" kind of.<p>If you're curious how out of control and wacky these sort of graphs can get, <a href="https://blueprintsfromhell.tumblr.com/" rel="nofollow">https://blueprintsfromhell.tumblr.com/</a> has a bunch of fun examples.
The video game industry is built arround that, game engines use that model all the time as gameplay scripting.<p><a href="https://dev.epicgames.com/documentation/unreal-engine/blueprints-visual-scripting-in-unreal-engine" rel="nofollow">https://dev.epicgames.com/documentation/unreal-engine/bluepr...</a>
I don't know, "node-based" interfaces as a concept seem to have made inroads into quite a number of (specialized) fields, e.g. image processing or movie postproduction.<p>My takeaway is that simply visualizing the AST of a procedural language doesn't do much in reducing the complexity and just makes it harder to read or edit long programs.<p>In contrast, visualizing data flow graphs can have real utility.<p>Also, the general question is who is the target audience: It seems pretty obvious to me that programmers who live and breathe code wouldn't be very enthusiastic about visual programming. But that might be different for other professions that don't have that kind of coding expertise.<p>Also, a lot of programming skill is about keeping the logical abstractions and runtime state in your head that your code will create - not so much reading what is on the screen. That's far easier if you have written the code yourself than if you have to get familiar with existing code.<p>Thanks to agents, the second case is becoming the dominating situation now, so clever visualizations that help you make sense of existing code and its runtime state might be in demand in the future.
Simulink, Labview, Bosch ASCET are all pervasive in control systems engineering, especially in European automotive applications.
I think PLCs are programmed using a mix of text and visuals. Or at least that's what I remember from uni. I'm not entirely sure why that is. I suppose it makes it a lot more obvious to your coworkers and management when you make spaghetti code, which I suppose can create pressure to not make a total mess of things.
Before PLCs were popular, technicians built automation systems using various types of relays. The documentation was done using "ladder diagrams" and the procedure was known as "ladder logic." So the first PLCs tried to take advantage of this knowledge by being programmed the same way since it was already familiar.<p>Later systems added to this by being programmable with structured text.<p>The first time I came across a system that was programmed entirely with relays I was completely blown away by what was possible. And also by how heavy, noisy and power-hungry it was for a portable device.
yeah Visual Basic 6, kind of a different thing but clicking on things to select the method etc is very similar
GNU Radio?
Blender shaders maybe?
Touchdesigner, VVVV, (Notch?) too. The big benefit here (besides dataflow programming working better for more pipeline-like programs) is that it's always runtime. This is a pretty big selling point for design where quick iteration and tweaking is important
scratch, thats super popular, but aimed at kids.
node-RED for PLC programming