I wrote an article saturday on visual programming which is very related to this, but my thinking is the opposite of this article.

Raw text is amazing at smaller scales. The ability to apply a bunch of intermediate incorrect transformations to reach a valid destination is invaluable (like doing a bunch of hacky find/replace).

Projectional editors like JetBrains MPS have tons of disadvantages vs text, and the few advantages don't make up for it.

Formatting is a silly problem to have, but far beyond that why are we manipulating text files directly rather than editing a live program (ala Smalltalk). Text can just be the on-disk serialization format you never look at.

(Raw text is still how you edit individual functions and methods in Smalltalk, there just isn't any actual text file on disk)

▲

whartung 3 days ago | parent | next [-]

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.

▲

sirwhinesalot 3 days ago | parent | next [-]

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).

▲

igouy 2 days ago | parent [-]

> we should be able to do better than text files

https://gtoolkit.com/

	▲	sirwhinesalot 2 days ago \| parent [-]
		Glamorous Toolkit is a lot more inline with what I'm thinking, being all about custom visualizations, but it's actually one level below where the tooling I want should be. The issue with Moldable Development is that it adds a substantial additional cost in development time that is then hopefully paid back with much improved debugging and analytics. That's a tough sell. The sort of tools you see in other engineering domains have tons of custom visualizations and such already built in, for all sorts of domains, even ultra niche ones (like battery design). That's why they can charge so much. Since all that stuff is just there ready to use, the cost is 0 (in effort, they cost a lot of money). Because GT needs to adapt to all the insane sorts of existing use cases and programming languages, it can't possibly implement all visualizations itself (nor even know what those visualizations should be like). What I'm thinking of is one level higher, where the entire development experience for a particular domain (which could be very broad) is entirely designed from the ground up with visualization in mind. Enso Analytics is a pretty good example. GT could be used to build something like that, but is not itself that.

▲

igouy 2 days ago | parent | prev [-]

Back-in-the-day Digitalk VisualSmalltalk PARTS:

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

▲

MaxLeiter 4 days ago | parent | prev [-]

Drop a link!

	▲	sirwhinesalot 3 days ago \| parent [-]
		Sorry for the late reply, here you go: https://btmc.substack.com/p/thoughts-on-visual-programming