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

At the beginning of my career I worked for a company that was started with two reverse-engineering tools: one to produce low-level, single method/function flowcharts and another for automatic extraction of high level components and connections between them. It retired the former and later - the latter and pivoted to static analysis tools: finding logical errors, security vulnerabilities, enforcing coding standards. So I have first-hand knowledge of what worked and what did not work.

The main problem with low-level code visualization was that it did not add much to the well-formatted code representation in most cases. As for the high-level architecture extraction tool, which is more close to the question in the article, many links on the diagram do not just involve header inclusion, module import, method calls etc that are relatively easy to extract (not without its own challenges with virtual and indirect calls though). Users wanted to see Inter process communications (socket, queues, pipes, http connections) and extracting those is an uphill battle though we introduced some of it (lots of custom, platform specific code). Between this and knowing which connections are important and which are less so, automatically extracted diagrams were of limited value.

I think it's kind of like the AI Winter -- there was a period of time when the software industry really went down a stupid path in regards to diagram-based code generation. A lot of kool aid was drunk over promises of making it so that everyone would be able to program.

But, of course, it turns out, someone still needs to understand and be able to debug all the nuances that makes complex logic systems complex, especially when they're cobbled together from many underlying systems.

The real goal should be to take good programmers and magnify what they can do. But since the industry bought so hard into the naive vision, the industry is behind where it should be on a smarter vision.

The OP is asking for diagram generation not code generation.

Which are two sides of the same coin, transformation of code Diagram.

The industry couldn't get the simple one of those (diagram -> code) to work well enough, how would they do the much more complex reverse?

Architectural and even library nuances can't be easily quantified to a particular UML symbol unless you go through the effort of classifying it for every library/design pattern, and keeping that up to date as well.

> Why aren't code visualization tools more popular? The options out there seem outdated

In my experience these tools generally exist to facilitate bikeshedding. The academic nature of UML makes it pretty useless in the real-world.

Something that could be useful is having a tool that uses knowledge about code to help you build a mindmap (but does not just puke the whole thing out). Huge bonus points for allowing the user to create late-bound relations and conceptual boundaries. Finally, one of these tools should be able to compare its output with the source, and indicate what has changed (through deletion/addition, or via VCS diff).