To expand on my answer above a bit, a few categories of tools I've (superficially) looked at or see others work on:
Code to UML (and the other way around): Generally have been clunky to use, and can't distinguish between important/non-important things. Might be useful for larger domain models, but that hasn't come up much for me.
Overview tools: typically generate a treemap of some sort from code directories and/or commit history. I can see how they might be useful to find specific hotspots in really large code bases, but I'm not so sure if that is a thing that's actually needed all that often (I certainly haven't)
Projectional editors are related and are interesting, but also don't feel all that practical. Incredibly hard to get right.
What I'm missing in the field: graphical debugging tools that e.g. visualize a run-time object graph, plot values/events, ...
Have gone through the same thought route. Very much agree.
GNU DDD does this really well, but it's unfortunately limited to just C/C++, and it still uses its old clunky Motif interface.
I just choose to trace the application package/s and not the 3rd party packages it uses, at least for the 1st run. Then I run any app feature that I want to explore. What I get is the truth, the pieces of code which have been executed to fulfill that feature. I then read the relevant source code shown by the tracer doing deep dive/high level reading as I deem fit. For complex features on a code base that is new to me, someone who gives me a high level overview helps, but even if not, the tracer helps me do it. I don't know but `dtrace` seems to be `detective trace`.
I haven't found yet more joyful experience of software visualization than a session with dtrace, especially when I combine it with live updating the app source code and see the change reflected.
Outside the lisp world where I can't do such tracing, well, I quirk!!!
[1] https://github.com/deadcode/Learning-CL--David-Touretzky/blo... [2] https://bitbucket.org/dmsurti/dtrace
Now I admit for large projects (~ >50k loc), visualisation could prove to be very useful for architects or new people joining the room. But most visualisations tools are very text oriented, because of the underlying language itself. So what you end up with is the name of the class/package/variable in a rectangle with lines drawn to another class. From where I stand, that's very easy for me to either quickly draw on paper or imagine it in my head. So the tools I've come across don't add much value.
Another point which is only speculation is that a number of users are not visual, and have a different way of processing data. They'd rather read/hear about the details and numbers to "understand" what is happening, rather than visualise them.
Good point, but it's only easy to draw or imagine if you already know everything involved. In my opinion software visualization should not just be about visualizing what you already know but instead about providing information that you don't know. So you don't need to go through all of your code files in order to draw that inheritance diagram.
"number of users are not visual"
I think I don't know any programmer who hasn't already scribbled some kind of diagram on a piece of paper ;)
I've concluded this by asking two question:
-Has no one made one? Not true at all. We have always more apps & software in general that you think.
-Is there any reasons for not knowing any good tools and not using them extensively other than they have not been useful in long run? No.
Would love to hear about any good ones.
What makes you think that? (I personally haven't noticed any signs pointing to that, which is why I'm curious)
In my opinion, it's not that useful. Any visualization tools should help the users understand and interpret the information.
But with this tool, all you can learn from the visualization is that code bases grow....
If there is a visualization tool can generate diagrams of a large code base and help me understand the code, I will buy it.