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.