I think it would be great to do the reverse - take existing programs and map out the calls in a graph structure that can be visually displayed.
Hardest part of looking at existing code base is to "mentally map" the call stacks and overtime, atleast for the way my brain operates, I tend to build a 2d map in my mind. It doesn't have concrete positions for blocks (functions), but there is a sense of structure in the brain that persists. I can come back to the code base and it is evoked automatically.
We need visual tools for examining codebases just like we have tools for examining database schemas. Perhaps its not that simple though.
Having worked in actual visual programming environments I'd argue that even the most trivial applications are too complicated to mapped out visually. There just isn't enough visual resolution in a screen, or for that matter, in your eye to render it sufficiently. Zoom out and lose detail. Zoom in and use lose context. I've seen programs printed out into huge graphs covering entire boardroom tables and I can assure you nobody benefited from the display.
Ironically the convoluted programs that people think this would be a solution for make for the most disgusting and hard to follow diagrams.
The whole thing maybe.
But often I'm in a function and I'd like to know "who calls this", or "what does this call". So being able to get a graph limited to the current function (node) and a couple of levels out on either end could be very helpful. Or maybe being able to mark two functions and see the ways they are connected (if at all).
I guess there might be some tools that do this though, haven't looked.
I’m looking at ways to improve the analysis to get more detail from apps, but it’s tricky. As far as I know, nobody’s made an ontology of computer science or source code patterns yet.
Creating the graph is easy compared to how much you might want to do to interpret it. Then we’ve data flow graphs to consider, and UI component graphs, dependency graphs, supported platform annotations, and ideally, telemetry from code execution in tests and production, and each can supplement or annotate control flow graphs and source code.
It’s a problem we’ll solve as a community but it’ll take a number of years before it’s general purpose enough that step one is load a program and step two is read and modify it... with everything you need neatly linked and annotated...
https://github.com/CoatiSoftware/Sourcetrail
https://www.patreon.com/sourcetrail/posts
For more on my thoughts of “understanding code automatically,” see https://github.com/CoatiSoftware/Sourcetrail/issues/750#issu... as an example.
My preference would be just as books, programmers and IDEs build mental models from source code, that eventually we could generically go from a collection of source files to identifying languages, build commands, and app starting points to multiple layers of graphs: control flow, data flow, cross-project references, and eventually — help programmers like an IDE would, but smarter, more like documentation written by a human with annotated examples from test cases and live code, etc.