Ask HN: Why aren't code diagram generating tools more common?

This is very hard. And since it's hard, it's not automated. And since it's not automated, it goes out of date very quickly. I think that's the fundamental issue: keeping around evergreen documentation is a lot of overhead. There is no connection between the code and the diagrams, so it's too easy to change the code and not realize that the diagram needs to be updated too.

Another thing is that it's really the most useful for new members. If you've been working on the infra for a while, you already know the structure and you don't need the diagram. So teams tend to just avoid the diagrams altogether.

Maybe you'd need a three dimensional model (really it's likely n-dimensional/hyperdimensional), 2D might not be enough.

Programming models get so convoluted with regards to state and interactions, both in-memory/in-process state and the stored state in databases/files.

Jurassic Park's 3D filesystem was a pie in the sky idea, what, 30 years ago? Holy crap it was 29 years ago or so. We've had REVOLUTIONS in 3D processing and games, and never even stratched the surface of basic 3D visualizations of code or data or filesystems or machine networks or the like.

And then even if you represent a diagram, it's useless without time visualization/traces, as kind of referred to by the RR debugger post. So for active code, you'd need simulation or actual run data to show what it does visually to be effective.

Really what's being dealt with here is probably related to theory of computation, and various results like the undecidability of the halting problem. The halting problem shows that even for very basic languages that are minimally Turing complete, the complexity shoots VERY QUICKLY to massive degrees of infinity/uncomputability.

So some catch-all visualizer for even general classes of Turing complete languages is probably impossible.

Maybe something like "this is a java spring app with well regimented separationg of data/domain classes and service classes"...

Even then once you get to database persistence ... wow.

And the amount of data you'd need to store for test runs.

Spring + TDD enforces a certain simplicity to a codebase, so perhaps you could make effective classes of visualization and tracing/replay visualization for that.

But it is telling these tools don't really exist, and attempts like UML were largely abandoned.

That said, diagrams can either be rare, focused, and useful; or common, unfocused, and distracting. Automated processes tend to generate the latter.

I keep bookmarking threads like this one, but I haven't found anything useful for me. The closest one was SourceTrail, which is unfortunately not developed anymore.

With so much hiring and onboarding going on, I am surprised there isn't a market (or an offering) for such tools.