You're absolutely right. Visual programs are much harder to generalize because they've been pre-abstracted for you to a specific use case.
Building controls are a popular field for visual programming because the "wires" seem like they'll be intuitive to non-programming tradespeople.
If we have a little visual program that controls the temperature in a room with a thermostat block and a baseboard heater, that's fun. We can play all kinds of games hooking up limit blocks and schedule blocks and whatever. Intuitive.
Imagine we have seven thousand rooms and some of them have only a baseboard heater but some have an air conditioner, some have a lighting interlock, some have a heat recovery unit. 16 possible configurations of a room and you have rooms in each set.
Now... apply a visual program across all of those sets.
In traditional programming this is simple. A data structure representing room configurations and few conditional statements in your function or loop or whatever. In visual programming you're mostly looking at either making 16 versions of the program and applying each to its associated rooms manually or else passing a bunch of conditional variables around.
Those variables aren't visual anymore. So now you have a whole layer of abstraction that's no longer visual. And really, the parts that fit into the visual model are usually the easy bits. The hard parts still require abstract reasoning about stuff that isn't linked together. Pretty soon you're just using the visual language to draw the inside of your "functions" but your high-level datalinks or scripts are entirely non-intuitive and might as well be in text.
Why can't conditional variables be "visual"? This is not clear to me - data flow and control flow are both visual (albeit their flavors of "parallel" composition and the like are incompatible, so they must never be conflated when shown diagrammatically) and conditional variables can be accounted for in control flow.
Say I have 100 rooms. Each room has 10 characteristics that might vary. Those 10 characteristics are going to be shown or referred to by about 10 different blocks... some are making decisions about the temperature, some are showing it on graphics, some are logging data.
That's 10,000 links. You can't actually draw lines for each of those links to the room information. It's literally impossible to put them on a screen, let alone process them visually. So you have to refer to the variables by name and you still end up with 100 links to draw between variable names and function blocks.
Once you refer to variables by name the relationship between the source and destination is no longer visual. The visual part is just inside any given encapsulated function. So now you're programming with parameter passing but instead of just typing text you're also pulling away to move the mouse and try to line blocks up on a grid all the time.
This should be pretty obvious while coding in text. Imagine every time a you call a function there has to be a line somewhere that represents that function call. It's too much visual information. You can abstract away some of it by saying "oh, we have a block here that goes out and grabs all the room numbers", but now a lot of the logic starts to depend on the contents of those blocks and it's no longer clearly visual.
Visual diagramming is great for roughing out an idea of how something works but enforcing a rigorous correspondence between the diagram and the function of the program turns out to be a lot of trouble for not very much gain.
Building controls are a popular field for visual programming because the "wires" seem like they'll be intuitive to non-programming tradespeople.
If we have a little visual program that controls the temperature in a room with a thermostat block and a baseboard heater, that's fun. We can play all kinds of games hooking up limit blocks and schedule blocks and whatever. Intuitive.
Imagine we have seven thousand rooms and some of them have only a baseboard heater but some have an air conditioner, some have a lighting interlock, some have a heat recovery unit. 16 possible configurations of a room and you have rooms in each set.
Now... apply a visual program across all of those sets.
In traditional programming this is simple. A data structure representing room configurations and few conditional statements in your function or loop or whatever. In visual programming you're mostly looking at either making 16 versions of the program and applying each to its associated rooms manually or else passing a bunch of conditional variables around.
Those variables aren't visual anymore. So now you have a whole layer of abstraction that's no longer visual. And really, the parts that fit into the visual model are usually the easy bits. The hard parts still require abstract reasoning about stuff that isn't linked together. Pretty soon you're just using the visual language to draw the inside of your "functions" but your high-level datalinks or scripts are entirely non-intuitive and might as well be in text.