The symbolic lookups and diagrams described are already implemented in modern IDEs. People who rely on relatively simple text editors and text / regex search may be less aware of this, of course.<p>I do agree that visualizations are lacking. In part this is because of difficulties in complete analysis, and rather than do half a job, they don't do any job at all. And in other parts its because different tools do a better job: for example, instrumenting profilers are better at showing control flow.<p>I generally want three kinds of things in my head when reading code: control flow, data flow and data shape.<p>But there are different resolutions to this. Control flow may be simple, at the method level; or it may be more complex, with asynchronous callbacks, queuing systems, RPC, web service requests and orchestrations controlled by configuration.<p>Data flow may be simply knowing where in the code a particular attribute is updated and where it is read and used to make a decision. But it's also about where the data came from ultimately - what all the ingredients are that go into its formation - and also what other data it in turn affects.<p>Data shape has to do with the simple shapes of structures, but diagrams are scarcely needed for that - a glance at the definition of the structure is enough to commit it to short-term memory. More interesting is global invariants, local invariants, longer chains (how you get to one distant structure from another via links), the database model, configuration data model, static data vs dynamic data.<p>Most of the interesting information is at a higher level than can reasonably be analyzed in most Turing-complete languages. The best info comes from profiling or debugging.