6 ms·

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

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.

atupis 7y ago
It would be pretty cool when you zoom out first you see methods of how they are linked. Then classes and how they linked together.
TsiCClawOfLight 7y ago
Have you tried sourcetrail?
wvenable 7y ago
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.
- som33 7y ago
  It's just a matter of a lot of research. I've been thinking for a long time that now that we have tonnes of memory and cpu power, its time to add hardware that keeps track of stuff and make things easier to understand. For instance when you look at hex in a file, you see a bunch of numbers, but it would be nice if there was some inference and cloud database of commonly used tropes/functions and could infer concepts, ideas of what the programmer was thinking. Currently with code, you get someones thoughts that are then translated into a language, then are then translated into machine code. It would be nice not to lose information regarding what does what in human readable language, I understand for performance reasons why programming languages as they currently are do what they do. But c and c++ were really designed when hardware and memory was expensive. So they are "too the metal" in terms of their model. I think reimplementing a basic machine, aka actual hardware design has to be done at the same time as a compiler is made, and work out the theory concepts behind it. The fragility of von neuman machines and their code has always bugged me, the machine can only blindly do what the hardware is designed to do, since hardware is all about speed, you want to minimize information, but for coding, it would make sense to have machines developed just for development and have "light code" for when you release it out into the wild. Either way I think there is plenty of innovation left, it's just a lot of research at the hardware and compiler level so that you have base foundations and abstractions to make real innovations in understanding how programs behave. One of the massive issues is not being able to understand cause and effect in programming which leads to bugs, because the brain can't make easy models of how code or algorithms will behave.
- vlovich123 7y ago
  I found the reverse. I had to do a tech debt cleanup of the code and found that doing an abstract diagram made it much easier to map out the interrelation between all the classes which was hard to keep in my head all at once. Also made it easier to communicate to others visually why it was spaghetti & easy to create a diagram about how I'd like to clean it up. I used PlantUML because what a lot of text -> visual things miss is that they don't provide the necessary knobs to tune the level of detail so doing the diagram by hand was a necessity. There may be multiple ways to look at something - sequence graphs, data flows - and additionally you don't want to capture all the details in the visualization, you want to be able to cut-off the diagrams at choke points where they're not helpful (e.g. I don't care about package X in the code) which is what all visualization packages try to do. This is directly analogous to geographic maps. Imagine if you viewed the map for a state/province whatever & had the local road network detailed. That map would be unusable & discarded quickly. Diagramming tools need to be able to take text & generate a visualization that you can zoom into/out of & lose/gain the appropriate level of detail necessary, be able to switch between different aspects (like you can with street view vs regular vs satellite, vs topography). I think the reason we don't have equivalent tools for programming is three-fold: 1. There's a lot of popular languages. Maintaining support for parsing & mapping that to the visualization abstraction is going to be a lot of work. Probably manageable though. 2. As engineers we tend to think in either solving the problem or not. No visualization is going to be good as a hand-drawn diagram in the moment nor is it probably good enough (at least the first version) as a vehicle for making the modification. 3. There's lot of type erasure/dynamism that's impossible to capture in code analysis (e.g. type-erased callbacks like `std::function`, `std::any`). That makes the visualization incorrect or cause it to fail prematurely.
  - DylanDmitri 7y ago
    Agree with you here. When working on more complex problems, I keep a hand-drawn diagram of the relevant code next to my keyboard. Often I'll spend a day sketching out 5 or 6 rough drafts before I arrive at an accurate understand of both the existing code how and how to portray it visually.
- ken 7y ago
  Whenever I've tried making dependency graphs of programs (usually the easiest type of visualization to create), I find they always turn up some crazy dependencies you never expected, and don't want. It's easy to hide one weird #include in a list of 20 other #includes. It's hard to hide an arrow going sideways halfway across your diagram. For visualization types other than dependency graphs or class hierarchies, it's tricky to do any sort of automatic code-to-diagram conversion, so I wouldn't expect there to be a lot of value in that. Even something simple like a state machine might be much simpler to see in diagram form, but it would take quite a bit of sophistication for a visualization program to look at 1000 lines of C and recognize that you're implementing a state machine. The visual form is more abstract, so you need to start there and have the computer compile it down. Going the other way is always harder. It's 1000 times easier to start with Python code and automatically convert it into machine code, than it is to take machine code and automatically extract a readable Python program from it. That's not because Python is inherently bad for reading or writing. The less abstract form, by its nature, is full of implementation details that don't matter in the more abstract form.
- magicalhippo 7y ago
  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.
  - GChevalier 7y ago
    Please someone do a PyCharm plugin for this!
  - Too 7y ago
    Visual studio can show a call-graph, containing both callers and callees to/from a function. "Who calls this" is standard feature of any IDE worth it's name, it's usually called find usages or find references.
  - lstamour 7y ago
    Sourcetrail is one such app. It recently went open source. I’ve been trying on spare time to contribute to it, it currently supports C++, Java and Python. 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://www.sourcetrail.com/ https://www.sourcetrail.com/ https://github.com/CoatiSoftware/Sourcetrail https://github.com/CoatiSoftware/Sourcetrail https://www.patreon.com/sourcetrail/posts https://www.patreon.com/sourcetrail/posts For more on my thoughts of “understanding code automatically,” see https://github.com/CoatiSoftware/Sourcetrail/issues/750#issuecomment-555861526 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.
- dkersten 7y ago
  My experience was different. I really enjoyed working in visual languages and found them quite pleasant to navigate. I also found that when applying good software engineering principles, visual languages can look very clear. Its just most users of visual languages aren’t professional programmers and never learned software engineering principles like abstraction. Here’s the thing: textual programming languages are also impossible to understand and follow if they don’t follow software engineering practices, but that’s often ignored because we’re used to programming in them. Well abstracted textual code is usually compared to badly abstracted visual code and textual languages are declared the “winner” (even if it shouldn’t be a competition at all).
- ivan_ah 6y ago
  If your codebase is in Python, you can generate a module-level dependency graph using `pydeps`: https://pydeps.readthedocs.io/en/latest/#usage https://pydeps.readthedocs.io/en/latest/#usage The graphs are overwhelming for anything beyond a smallest project, but I find them useful as an overview. In other words you can see "what is there" but maybe not understand "how it works."
fragmede 7y ago
There is an absolute dearth of tools, especially modern ones, in this space, but the tools to generate call graphs have existed for quite a while. Egypt will parse output from gcc and output a dot file for gnuplot/Graphviz. There may also be D3.js support in places. I agree we need visual tools, especially when trying to maintain a large codebase, but only the largest companies can sponsor development of an in-house tool for their codebase, and many of them won't. Maintaining code isn't sexy and doesn't make for new features to sell.
solidasparagus 7y ago
We look at compute graphs in deep learning, but it isn't very valuable because the graphs are so complicated. Among other issues, it's difficult to create a visualization of a compute graph that represents the time dimension well.

atupis 7y ago

It would be pretty cool when you zoom out first you see methods of how they are linked. Then classes and how they linked together.

TsiCClawOfLight 7y ago

Have you tried sourcetrail?

wvenable 7y ago

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.

som33 7y ago
It's just a matter of a lot of research. I've been thinking for a long time that now that we have tonnes of memory and cpu power, its time to add hardware that keeps track of stuff and make things easier to understand. For instance when you look at hex in a file, you see a bunch of numbers, but it would be nice if there was some inference and cloud database of commonly used tropes/functions and could infer concepts, ideas of what the programmer was thinking. Currently with code, you get someones thoughts that are then translated into a language, then are then translated into machine code. It would be nice not to lose information regarding what does what in human readable language, I understand for performance reasons why programming languages as they currently are do what they do. But c and c++ were really designed when hardware and memory was expensive. So they are "too the metal" in terms of their model. I think reimplementing a basic machine, aka actual hardware design has to be done at the same time as a compiler is made, and work out the theory concepts behind it. The fragility of von neuman machines and their code has always bugged me, the machine can only blindly do what the hardware is designed to do, since hardware is all about speed, you want to minimize information, but for coding, it would make sense to have machines developed just for development and have "light code" for when you release it out into the wild. Either way I think there is plenty of innovation left, it's just a lot of research at the hardware and compiler level so that you have base foundations and abstractions to make real innovations in understanding how programs behave. One of the massive issues is not being able to understand cause and effect in programming which leads to bugs, because the brain can't make easy models of how code or algorithms will behave.
vlovich123 7y ago
I found the reverse. I had to do a tech debt cleanup of the code and found that doing an abstract diagram made it much easier to map out the interrelation between all the classes which was hard to keep in my head all at once. Also made it easier to communicate to others visually why it was spaghetti & easy to create a diagram about how I'd like to clean it up. I used PlantUML because what a lot of text -> visual things miss is that they don't provide the necessary knobs to tune the level of detail so doing the diagram by hand was a necessity. There may be multiple ways to look at something - sequence graphs, data flows - and additionally you don't want to capture all the details in the visualization, you want to be able to cut-off the diagrams at choke points where they're not helpful (e.g. I don't care about package X in the code) which is what all visualization packages try to do. This is directly analogous to geographic maps. Imagine if you viewed the map for a state/province whatever & had the local road network detailed. That map would be unusable & discarded quickly. Diagramming tools need to be able to take text & generate a visualization that you can zoom into/out of & lose/gain the appropriate level of detail necessary, be able to switch between different aspects (like you can with street view vs regular vs satellite, vs topography). I think the reason we don't have equivalent tools for programming is three-fold: 1. There's a lot of popular languages. Maintaining support for parsing & mapping that to the visualization abstraction is going to be a lot of work. Probably manageable though. 2. As engineers we tend to think in either solving the problem or not. No visualization is going to be good as a hand-drawn diagram in the moment nor is it probably good enough (at least the first version) as a vehicle for making the modification. 3. There's lot of type erasure/dynamism that's impossible to capture in code analysis (e.g. type-erased callbacks like `std::function`, `std::any`). That makes the visualization incorrect or cause it to fail prematurely.
- DylanDmitri 7y ago
  Agree with you here. When working on more complex problems, I keep a hand-drawn diagram of the relevant code next to my keyboard. Often I'll spend a day sketching out 5 or 6 rough drafts before I arrive at an accurate understand of both the existing code how and how to portray it visually.
ken 7y ago
Whenever I've tried making dependency graphs of programs (usually the easiest type of visualization to create), I find they always turn up some crazy dependencies you never expected, and don't want. It's easy to hide one weird #include in a list of 20 other #includes. It's hard to hide an arrow going sideways halfway across your diagram. For visualization types other than dependency graphs or class hierarchies, it's tricky to do any sort of automatic code-to-diagram conversion, so I wouldn't expect there to be a lot of value in that. Even something simple like a state machine might be much simpler to see in diagram form, but it would take quite a bit of sophistication for a visualization program to look at 1000 lines of C and recognize that you're implementing a state machine. The visual form is more abstract, so you need to start there and have the computer compile it down. Going the other way is always harder. It's 1000 times easier to start with Python code and automatically convert it into machine code, than it is to take machine code and automatically extract a readable Python program from it. That's not because Python is inherently bad for reading or writing. The less abstract form, by its nature, is full of implementation details that don't matter in the more abstract form.
magicalhippo 7y ago
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.
- GChevalier 7y ago
  Please someone do a PyCharm plugin for this!
- Too 7y ago
  Visual studio can show a call-graph, containing both callers and callees to/from a function. "Who calls this" is standard feature of any IDE worth it's name, it's usually called find usages or find references.
- lstamour 7y ago
  Sourcetrail is one such app. It recently went open source. I’ve been trying on spare time to contribute to it, it currently supports C++, Java and Python. 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://www.sourcetrail.com/ https://www.sourcetrail.com/ https://github.com/CoatiSoftware/Sourcetrail https://github.com/CoatiSoftware/Sourcetrail https://www.patreon.com/sourcetrail/posts https://www.patreon.com/sourcetrail/posts For more on my thoughts of “understanding code automatically,” see https://github.com/CoatiSoftware/Sourcetrail/issues/750#issuecomment-555861526 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.
dkersten 7y ago
My experience was different. I really enjoyed working in visual languages and found them quite pleasant to navigate. I also found that when applying good software engineering principles, visual languages can look very clear. Its just most users of visual languages aren’t professional programmers and never learned software engineering principles like abstraction. Here’s the thing: textual programming languages are also impossible to understand and follow if they don’t follow software engineering practices, but that’s often ignored because we’re used to programming in them. Well abstracted textual code is usually compared to badly abstracted visual code and textual languages are declared the “winner” (even if it shouldn’t be a competition at all).
ivan_ah 6y ago
If your codebase is in Python, you can generate a module-level dependency graph using `pydeps`: https://pydeps.readthedocs.io/en/latest/#usage https://pydeps.readthedocs.io/en/latest/#usage The graphs are overwhelming for anything beyond a smallest project, but I find them useful as an overview. In other words you can see "what is there" but maybe not understand "how it works."

fragmede 7y ago

There is an absolute dearth of tools, especially modern ones, in this space, but the tools to generate call graphs have existed for quite a while. Egypt will parse output from gcc and output a dot file for gnuplot/Graphviz. There may also be D3.js support in places. I agree we need visual tools, especially when trying to maintain a large codebase, but only the largest companies can sponsor development of an in-house tool for their codebase, and many of them won't. Maintaining code isn't sexy and doesn't make for new features to sell.

solidasparagus 7y ago

We look at compute graphs in deep learning, but it isn't very valuable because the graphs are so complicated. Among other issues, it's difficult to create a visualization of a compute graph that represents the time dimension well.