My singular problem with visual programming is simply the amount of detail necessary in modern programming.

Code is flat out complicated, with lots and lots and lots of steps, each with perhaps even more detail.

And it's hard to do that efficiently with visual editors. Imagine a display with instead of thousands of lines of code, you have thousands of symbols.

Or, the visual editors break things down in to components that are so small they do not convey the "big picture" well.

It's a personal complaint with the way Smalltalk works. Lots of methods, small (ideally) snippets of code, all viewed in isolation.

It's common (at least for me) to put related code together in the source file. It's useful to scan the whole file to get a feel for the flow of the code, and the system. Looking at isolated code, out of context, has always been a struggle for me. There's a reason my code is not sorted alphabetically by function name.

Maybe if you organized code visually, that is, perhaps the upper left is the start up code, the lower right is some core math all collected together like beads in a pot. "All red ones go here, all the 1" ones go there".

Granted I have not worked on such a tool or such a project. But the linear presentation of code as structured text has worked well for me, even when I bounce around between modules in the IDE.

Indeed, putting related code together in the same source file is one of the ways we cope with complexity.

Though it too breaks down, because the relations between various bits of code may be so complex that there's no good way to "linearize" them.

And you should be documenting your code, but documentation comments take up space on the screen since they are linearly arranged in the same file, so you see less functions at a time.

Imagine as an alternative that the documentation was presented on a side view of the functions, like how you can open two files side by side in VSCode. Then you'd be able to see many more functions at the same time.

If you have any unit tests then it would be great if you could see them (and run them) while editing the function. In Rust you can put tests in the same file as the function (very nice) but usually on a submodule at the bottom of the file rather than near the function itself. Again, the problem of trying to linearize everything in a single file.

The issue with visual programming tools is that they don't put any thought into this. On how they could actually help get you the information you want to see. Instead they focus on letting you make cute drawings.

It's a UX problem, we should be able to do better than text files, even if what we end up editing is still text (because of all the advantages it has).

Back-in-the-day Digitalk VisualSmalltalk PARTS:

https://www.wirfs-brock.com/allen/files/digitalk/VSbrochure....