I'm looking forward to one day being shown a "visualizer" that actually gives me sane insight into the structure, instead of some wibbly-wobbly animated node graph that I have to click around and zoom in/out. These things can sometimes look pretty, but usually I'm left none the wiser about the actual structure.
Completely agree - Gource is also mentioned here and does something similar.
Probably more useful tools are CodeCity and JSCity, that go beyond the layout of the repo and get to the function level, so they are able to give potentially useful insights like coupling or complexity of classes. In any case, there's a long way to go as far as the effort of running these programs actually being worth it.
What would that look/behave like? I ask because I'm starting out on making some tooling for gaining insights into coupling and coherence in ruby, and I'm at a brainstorming phase.
E.g. automatic domain concept detection and suggested refactorings around domain concepts.
Re-organizing file systems into virtual filesystems based on multiple views/perspectives on the project, etc.
Any ideas you have would be really good timing to hear about
Not really regarding what, but on the how front, I remember that one guy invented what he called "hive plots", and he seems to be claiming they're some kind of a panaceum to so called "hairball" plots:
Up to about 1fps. The DOM tree continues to gather its factions together under one banner. Meanwhile, the smaller but more easily organized devtools and webidl factions are making an early power play.
In the same vein, gource is pretty cool. It shows the same sort of graph, but animated as it changes over time. So you can watch the project develop, and even see who was working on which files at which time. It's great to put up on a screen during launch celebrations or whatever.
Why does it move and wiggle? It makes it unnecessarily hard to click on nodes. Also, it took me at least 30 seconds to figure out how to start at all as I didn't notice the small inputs in the upper lefthand corner.
Because it's using a graph layout algorithm called Force Directed Graph Drawing, where you basically connect the nodes together with springs and then run a simulation.
The algorithm's really simple and works pretty well, but unfortunately it doesn't really have the concept of 'finished' --- you just keep simulating until it looks right. Some implementations watch for small deltas and when the change rate gets low they stop the simulation, but it can take a while and people frequently don't bother.
I think it says good things about Wren that the largest section, by far, is tests. Then a big blob for docs. The actual language interpreter itself is quite small.
Being able to search/filter by name. I often find some file being included in the build and its a pain to track down exactly who uses it (ok, not a huge pain, but it would be so much easier to do it in this)
