I know of several for specific fields (Dark for backends, TouchDesigner for live graphics/multimedia), but none that are more generalised, open, or in wide use.
It feels like an underdeveloped area that’s ripe for exploration and experimentation.
1. Writing it is a pain. This is a minor gripe, comparably, but if you already know what you want it is very, very hard to beat just typing out a word. Dragging and dropping through menus makes every little action take too long for comfort. You also miss out on the syntactic sugar that makes coding so much more bearable: little, everyday things, like indexing into an array, or incrementing a value, end up taking just as long as putting in any other function.
2. The information density is atrociously low. Intuitively, it seems like the opposite should be true, after all, in a real programming language you're missing out on pictures and icons and a whole dimension of space. But it turns out that the whole "function reads top-to-bottom" thing packs a lot of flow information.
3. Flow-based value passing robs you of variable naming. In a language like LabVIEW, you very rarely use typed out variable names. Most are replaced by unnamed wires. This subtle feature strips the program of a lot of contextual information, making it hard to read.
4. Linting. If you thought making consistent, presentable code is hard in 1D space, in 2D it's basically intractable. The amount of time I spend futzing with wire pathing is infuriating.
If there is any chance that a project will require software developers some day (if you're starting a business, or inventing something novel, it will) just bite the bullet and use a real programming language. Visual programming just attempts to make the easiest part of programming easier, and makes everything else more painful in the process.
I found graphical programming to be physically debilitating due to eyestrain and wrist fatigue. Granted, this affects each person differently, and I also don't use CAD for the same reason. I can type text with my eyes closed, or while I shift my visual focus away from the screen.
I think a reason why LV programs always seem so unreadable is that the sheer physical effort to clean them up gets the best of the people doing the programming.
A general issue with graphical programming is that you're responsible for the developer interface, and really sweating the details to make it tolerably ergonomic is phenomenally costly in time and effort -- think of how many programmers are employed by Apple or Microsoft.
In contrast, when experimenting with a new or improved text based language, you can piggyback off of existing IDE's or even basic text editors, and get a running head start on adoption by a user community. And the economics are such that languages and IDEs can be supported as open source projects.
There are text based dataflow programming langauges, and I think if LV adopted one of them as an option, folks would stop using the graphical environment after getting over the initial hump of learning to program.
I always show people this:
https://www.ni.com/docs/en-US/bundle/labview/page/gmath/nonl...
Scratch programs also become messy quickly as the complexity increases. Normal code is more compact and easier to actually follow.
Also, in most languages, you don't have to worry about the two-dimensional layout of your code.
I bet most people saw your comment and thought of things like befunge [0] (and scratch of course), but I smiled when I thought of fortran 77...
Do you know vvvv gamma? It's a visual programming environment for .Net. Its language (called VL) combines dataflow programming with features known from object-oriented and functional programming.
One big aspect is handling state. Connecting nodes without side effects is great when each frame is a cycle and all you have to do is transform data into a final result. When actual state is involved it becomes hacky or impossible to do in with only transformations. Other similar hurdles are branching and IO.
The other is having general purpose programming underneath. Shader languages enable a lot, but using a real programming language like C++ somewhere not only opens the door to whatever you need, but allows you to integrate all the libraries already made as well as call out to OS IO APIs etc.
It is amazing though how nice it is to work with an integrated and fluid environment where iterations are updated in real time and errors are narrowed down for you, not to mention profiling broken down by node.
For speed: it's really hard to beat the speed of data entry via keyboard. A well-designed set of keyboard accelerators would cover a lot of ground on making visual programming languages comparable to keyboard programming speed, but I haven't seen anybody pull it off yet.
For scalability, and in the sense I mean scalability of project complexity from a toy desktop project to a distributed system deployment or a low level embedded system: the vast bulk of tools that are available for supporting large projects are built around text and the fact that it's relatively easy to translate a tool working in one text-based language to another text-based language. Git doesn't care what language you're using; it's all text. Diffing tools don't care what language you're using; they diff lines of text. As tools like Copilot grow, they will start by disproportionately giving a power boost to text-based languages because they are built to work with text-based languages.
Anything that's going to work with a visual programming language in a way that is as robust as these tools do needs to treat the language as an abstract syntax tree, not a collection of lines separated by line breaks. And the tools to do that are going to have to be written almost from scratch; it's simply an underdeveloped ecosystem because there's so much fungibility between different text-based languages in terms of allowing tools that work on one to work on another.
There are some systems which try to make it just a straight-forward description --- Drakon Editor comes to mind.
Scalability is an issue --- but screens are larger these days, so may be more workable (I've managed some decently complex models in BlockSCAD:
https://www.blockscad3d.com/community/projects/1385418
A further issue is that if one uses modules/functions, one ends up w/ just a textual description of the algorithm trapped w/in a series of connected/nested blocks.
I prefer to work this way, but I've crashed-burned hard on installation/usage w/ more tools than I can recall off the top of my head (pyFlow, Ryven, GraphSCAD, clikscad, &c.) --- currently I'm just using BlockSCAD and pasting the code into OpenSCAD/RapCAD. I hope that Nodezator (node programming tool done w/ pygame) will work out, but I'm waiting for it to have branches and loops.
Programming languages in common use are way too general to really benefit from a structural editing workflow as seen in Scratch. Meanwhile, other VPL's cannot naturally express the kinds of abstractions that turn out to be critical when programming "in the large", as often happens in professional settings.
For serverless functions/API pipelines, check out (formerly Integromat): https://www.make.com/en
Some even use it for procedural modeling ! (Houdini, Blender)