[lliamander]

In my experience, there are three things that visual programming tools make difficult:

* abstraction

* version control

* test automation

Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects.

The one asterisk I would put on that is tools in which the visualization is based upon an actual, human readable, programming language. I did some work with XSLT back in the day using a visual programming tool, and it worked reasonably well.

[analog31]

An interesting thing about things like version control and test automation is that they are almost like "meta interpreters" that interpret your code, but do so for purposes other than executing it. Syntax checking and linting come to mind too. Those things are possible, not so much because the program is in text format, but because it's in an open format that anybody can parse.

If a visual programming language stored its programs in a human readable or at least open format, then it would be possible for people to create those tools for it. But then, people would start writing and editing the program directly in its storage format, and it would cease to be visual programming.

[SAI_Peregrinus]

The really funny bit is that the classic visual programming tool LabView is designed mostly for test automation. But it ends up practically requiring the creation of unmaintainable spaghetti (this[1] being a classic example) and there's no test automation possible for it. It's a test automation platform so complex it needs (but doesn't have) test automation for its automation of your tests.

[1] https://thedailywtf.com/articles/Labview-Spaghetti

[bmitc]

No one should ever write code like that and no experienced LabVIEW developer would find that anywhere close to acceptable. And there are no doubt analogs in the text-based world, except you may not even know it because the structure isn’t as visible.

Also, there are certainly test frameworks for testing LabVIEW code. NI has a few but then JKI, a third party company, has multiple testing frameworks including Caraya, which is similar in philosophy to something like FsUnit for F# or Elixir’s ExUnit.

https://github.com/JKISoftware/Caraya

[protomyth]

abstraction

I do wonder why some concept likes building chips doesn't make it into visual environments? I should be able to pass a chip with inputs and outputs to others.

[nitrogen]

It does in some. Visual programming environments are common for setting up the giant sound systems (think hundreds of channels of high-quality audio) that run everything from movie theaters to conference venues to parliamentary halls to amusement parks. Some of them support encapsulation of audio or logic elements into reusable packages.

Another technique they use for abstraction before that point include one-to-n on-page connectors and multi-signal buses when the visual wires get to be too cumbersome.

[DonHopkins]

Snap! supports user defined blocks, first class functions, lexical closures, eval/apply, and even call-with-current-continuation. See the summary and description I posted in reply to the GP.

[whatusername]

Node Red "Nodes" perhaps?