3 ms·

I suspect this is an area that is part of the essential complexity [1] of programming. Reachability, variable liveness, pointer aliasing, etc. are undecidable p

I suspect this is an area that is part of the essential complexity [1] of programming. Reachability, variable liveness, pointer aliasing, etc. are undecidable problems for arbitrary programs. Also, the control flow graph of most non-trivial programs is probably too complex to visualize in a usable way. However, there is still a lot of room for improvement in compilers and debuggers. If I could tell the compiler to instrument my code to track the values that I care about, and then have the debugger visualize the flow of information through the system, that would be very useful. It wouldn't guarantee that the data flow analysis applies to subsequent runs of the program, but it could reduce the amount of time spent reading and debugging code. [1] https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet

vaughan 3y ago
Something that gives me hope is that I haven't seen anyone prioritize debuggability in a modern programming language or even a framework. Vale is maybe the first getting close: https://verdagon.dev/blog/perfect-replayability-prototyped https://verdagon.dev/blog/perfect-replayability-prototyped. I think there is a new era yet to come. > probably too complex to visualize in a usable way You can always abstract the complexity. A simplification of the control flow graph at the function level. As an example, I want to understand the Postgres codebase better...there are a lot of very visualizable things going on there. If you look at lecture slides on relational DBMS, there are lots of diagrams...so why can't be view those animating diagrams as the code executes. I was thinking of instrumenting the code to get a trace of every function call and its arguments, and then filter that and visualize it. The key to this approach working though is a think ultimately we need to write our code and organize our code such that it can be easily visualizable. The purpose of code is for humans to understand it, otherwise we are writing assembly.
- Terr_ 3y ago
  > I haven't seen anyone prioritize debuggability Static-checking tools and strongly-typed languages: "Are we a joke to you?" Finding and removing bugs before the code runs is still debugging.

vaughan 3y ago

Something that gives me hope is that I haven't seen anyone prioritize debuggability in a modern programming language or even a framework. Vale is maybe the first getting close: https://verdagon.dev/blog/perfect-replayability-prototyped https://verdagon.dev/blog/perfect-replayability-prototyped. I think there is a new era yet to come. > probably too complex to visualize in a usable way You can always abstract the complexity. A simplification of the control flow graph at the function level. As an example, I want to understand the Postgres codebase better...there are a lot of very visualizable things going on there. If you look at lecture slides on relational DBMS, there are lots of diagrams...so why can't be view those animating diagrams as the code executes. I was thinking of instrumenting the code to get a trace of every function call and its arguments, and then filter that and visualize it. The key to this approach working though is a think ultimately we need to write our code and organize our code such that it can be easily visualizable. The purpose of code is for humans to understand it, otherwise we are writing assembly.

Terr_ 3y ago
> I haven't seen anyone prioritize debuggability Static-checking tools and strongly-typed languages: "Are we a joke to you?" Finding and removing bugs before the code runs is still debugging.