The strength of visual programming is not in visualising code, but rather, visualising programs.
At a small scale, textual code can be very concise, expressive, compact, efficient and fast to write. But at a large scale, writing thousands of lines of code in text files in folders makes it very difficult to understand how the pieces of a program connect. To overcome this, we rely on file naming conventions, frameworks or writing documentation to understand how the various parts of text relate to each other.
Programming with nodes and wires is a way of visualising those relationships by creating a map of the program. Similar to maps of the real world, those maps may be complex and not easy to understand. But those maps show that there is complexity. what we can learn from maps of the real world? Well: zoom level matters. When we want to understand the world, we look at countries. When we want to get to the next city, we look at the road level.
In my opinion, visual programming environments are transparent and honest about the underlying complexity of a program. Contrast this with countless folders full of files filled with thousands of lines of code.
Such repositories of code can be very difficult to navigate and get around. Yes, frameworks and conventions can help to understand already learned organisational systems (example from the real world: “I learned to navigate American cities designed on a grid of streets, but I get lost in Europe“).
If we compare textual coding to visual programming, we should not only focus on the expression of low level logic and primitives, but also on the organisational aspect of programming. I think there is still a lot of potential for both textual coding and visual programming tools to create better wayfinding systems.
