Will Crichton

3. Computers are not as good at symbolic reasoning (except theorem provers), and concrete tracing is probably a simpler version of abstract tracing (ie where variables are unspecified and intermediates are properties).https://twitter.com/wcrichton/status/1351684351784849411 …

So where does runtime vis fit: if tracing helps us understand how a process works, vis helps us understand what the process produces. These are both important! If I just show the data, the process is obscured, and vice versa.

It's fundamentally hard for runtime vis to capture time, causality, dataflow, abstractions, etc. in a way that's (IMO) easier to see in a program text. Sorry the explanation is a bit sprawling but that's my general sense.

I totally agree that "show the data" is insufficient on its own. But more broadly, I want tools that leverage runtime data to help us answer these questions w/o manual tracing. Whyline is one great example of this -- assisting a task that would normally take lots of tracing

Abstraction is indeed tricky. Interesting to think about type systems in this context. Can catch issues, but I often have to manually trace to localize the problem. WM aids can help -- eg, hover on variable to see its type

Based on personal experience, having the code + granular example state available is often a nice combo to understand a process. I can start w/ examples, assume certain generalizations, and then check against the actual code