[crq-yml]

There's a correspondence between where node-and-wires works best and where the problem statement prefers something like a circuit diagram because it's synchronization-heavy. Games need a lot of this, and so do audio apps. The problem is that as you do more compute on the workload and need more "plain old synchronous algorithms" to process it, that holds true relatively less often, so it's a solution disproportionate to what production tools actually need.

I did a survey of the popular VPL environments last year and found Blender's implementation notable for what it didn't do. It exposes node-and-wire UI elements and the scripting for them in Python; all further details are delegated to each subsystem. So shaders, video, etc. have no relationship within their programming model, just UI similarity.

Add to that the aspect of - why are programming languages always going for plaintext representation - and it's because of the tooling ecosystem. We have a huge investment in text editing and text processing, and in typing on standardized keyboard layouts, on speech-to-text and vice versa, and lately, on text generation language models. We have made that stuff really cheap and fast for everyone, in the same way that when Blender did node-and-wire, they elected to make the paradigm as a whole cheaper to reuse in a customized way, versus investing heavily in one particular implementation and trying to extend it to many scenarios.

I think part of the issue is that we design VPLs without taking any interest in draftsmanship - the traditional core skillset for working with "visual language". Instead we use mouse pointers and touchpads and treat it as a data entry problem that has to be structured right away instead of allowing sloppy syntax.