It’s about abstractions, and a lot of the time visual programming tools don’t get it right. Either they are too abstract and your limited to a set of nodes/blocks that are not powerful enough and adding more is challenging because the abstraction is so high there’s lots of overhead to get there, or the abstraction capabilities are too low and the ability to encapsulate and extend visually programmed code for reuse in other places or larger projects is hampered by the design.
About the only “general purpose” visual programming language I’ve ever come across that is genuinely trying to be able to do all of it, is DRAKON https://en.m.wikipedia.org/wiki/DRAKON
And even then, complexity can be a challenge because depending on how the software is architected the diagrams get unwieldy to read as more logic lives on a single layer… DRAKON does have a pair of little tricks that makes it a bit less confusing to work with than a lot of node based programming tools. The first is that lines cannot cross so you avoid the tangled knot diagram issue, the logical flow is relatively clear from your entry points to your exit or loop back to start. The second is that it serves as an abstraction to other programming languages, allowing for use of traditional tools and techniques to debug and analyse the output programs if needed, and then once you’ve identified the problem you can make changes to the diagram, export and then compile the program again after confirm your diagram changes had the desired results in the intermediate format.
And before anyone asks what’s the point why not just program in the target language? First I’d like to point out that TypeScript is a thing, and then second I’d like to highlight that it was designed to aid in the comprehension and maintenance of algorithms in the aerospace software world, it’s meant to allow you to look at a diagram see the data flow and logical code paths and visually check that you haven’t forgotten things, heck you could confirm you had covered all your necessary conditions with some coloured pencils on a printout… which might feel foolish in an era of automated checking tools which we have today, but this was developed in the the Soviet Union in 1986 as part of the Buran space program, it solved their genuine needs for how to make checking code for correctness easier for humans, and has stuck around because even with automation it’s one of the few visual programming languages that managed to strike the balance between going to high level or giving too few tools for abstraction.
Nothing is perfect of course, it has issues, like every programming language does, but it’s been a useful little tool from time to time when I needed to collaborate on fiddly algorithms with non-programming experts who understood what the software needed to be doing way better than I did, and I understood way better how to make the software do it than they did. I’d encourage anyone who ever gave visual programming a shot to check it out even just for the sake of curiosity, and possibly learning a useful new flowchart diagramming standard even if you never use the compiler.
About the only “general purpose” visual programming language I’ve ever come across that is genuinely trying to be able to do all of it, is DRAKON https://en.m.wikipedia.org/wiki/DRAKON
And even then, complexity can be a challenge because depending on how the software is architected the diagrams get unwieldy to read as more logic lives on a single layer… DRAKON does have a pair of little tricks that makes it a bit less confusing to work with than a lot of node based programming tools. The first is that lines cannot cross so you avoid the tangled knot diagram issue, the logical flow is relatively clear from your entry points to your exit or loop back to start. The second is that it serves as an abstraction to other programming languages, allowing for use of traditional tools and techniques to debug and analyse the output programs if needed, and then once you’ve identified the problem you can make changes to the diagram, export and then compile the program again after confirm your diagram changes had the desired results in the intermediate format.
And before anyone asks what’s the point why not just program in the target language? First I’d like to point out that TypeScript is a thing, and then second I’d like to highlight that it was designed to aid in the comprehension and maintenance of algorithms in the aerospace software world, it’s meant to allow you to look at a diagram see the data flow and logical code paths and visually check that you haven’t forgotten things, heck you could confirm you had covered all your necessary conditions with some coloured pencils on a printout… which might feel foolish in an era of automated checking tools which we have today, but this was developed in the the Soviet Union in 1986 as part of the Buran space program, it solved their genuine needs for how to make checking code for correctness easier for humans, and has stuck around because even with automation it’s one of the few visual programming languages that managed to strike the balance between going to high level or giving too few tools for abstraction.
Nothing is perfect of course, it has issues, like every programming language does, but it’s been a useful little tool from time to time when I needed to collaborate on fiddly algorithms with non-programming experts who understood what the software needed to be doing way better than I did, and I understood way better how to make the software do it than they did. I’d encourage anyone who ever gave visual programming a shot to check it out even just for the sake of curiosity, and possibly learning a useful new flowchart diagramming standard even if you never use the compiler.