It's important to take the perspective that the Silicon Valley isn't an incubator of technology, but of business models.

Yahoo Pipes being free is exactly what killed them. Without a sustainable business model, they could not last.

Visual programming just doesn't make sense in a world where "low-code" users can safely be assumed to be using llms

Last year, I came up with Breadboard Programming[1] which is visual programming using Node-RED but with a different perspective, that of a breadboard[2]. The point is take another perspective on programming and to find new parallels to how electronics are created using breadboards.

Breadboarding is prototyping but with the intention of throwing everything away or iterating by simply copying and pasting the entire code base and then throwing it away. The difference to typical software prototyping is that the prototype can easily be copied and iterated on. Normally prototypes mutate into the final product and then remain those mutated monsters that we were going to refactor before they went into production.

[1]: https://blog.openmindmap.org/blog/breadboard-programming

[2]: https://en.wikipedia.org/wiki/Breadboard

I disagree with some of your points:

- Higher level abstractions - I don't think that's a usage of high level abstraction I'm familiar with, or else it's not true. You can have very very high level abstractions in text code, you can have very low level abstractions in visual programming (max msp). This also goes for the point about optimization in text languages.

- Less hidden state - this really depends on the visual programming language. The geometry node editor in Blender has tons of hidden state - what are the inputs to your program, what are the outputs, how is it applied, etc.

- Less configuration - I have no idea, but my guess is you're thinking of something like Rust where library A uses image type X and library B uses image type Y and you need to write code to convert between X and Y yourself. I don't think this is inherent to visual programming - it's just a consequence of having a large, complex ecosystem with independently evolving parts.

- No syntax to remember - There's still syntax, it's just visual syntax. What does this squiggle mean? What does this color mean? What about this box around things? And unlike text, where you can just write what you see, even if you know what something is with visual programming you might not know how to replicate it (which menu button, what conditions are required, what selection do I have to make, etc), google it, etc.

- Looping and recursion - This is a failing point in visual programming languages I'm familiar with, but I don't think there's anything stopping a visual programming language from offering functions, looping, and recursion.

- Optimization - I touched on this above, but higher level abstraction makes _more_ opportunity for compilers to optimize. Specifically, in visual programming languages, there's no inherent concept of a "sequence" of calculations as there are in imperative languages, so compilers can freely parallelize.

Then: errors and run-time feedback - yes, this is true of most visual programming languages and is super great. It's equally true for many non-visual programming languages (e.g. rust).

The point about discoverability is good, and I agree. Just knowing what you can do in a programming language is very hard (the first steps). Generally in visual programming languages all the parameters are shown right there on the screen.

Here are my extra advantages to visual programming languages:

- I think it's good to make a distinction between control flow graphs and data flow graphs. IMO representing state machines in text based languages is pretty bad and understanding complex call flows etc can be very difficult. Most visual programming languages are purely data flow, but I think a control flow graph programming language would be very good at this.

- Another advantage of visual programming languages is you don't need to come up with names in order to reuse values. Having to name things isn't a joke, and seeing lines and arrows is easier to grok then trying to 1. understand what a complex name means (and maybe forcing yourself to ignore it if the name is bad) and 2. remembering that name so you can mentally connect uses.

That said, there's no need to force these to be mutually exclusive. You could mix them (allow text within the graph, or refer to the graph from text, allow making some files graphs or some text, etc), or even freely convert between them (luna lang, which appears to be thoroughly dead atm but here's some remnants: https://github.com/Luna-Tensorflow/luna).