Tracers for debugging and program exploration
Shardul Chiplunkar, Cl\'ement Pit-Claudel

TL;DR
This paper proposes a debugging approach centered on providing programmers with a complete, time-ordered trace of program execution to facilitate hypothesis generation and understanding of software behavior.
Contribution
It advocates for a trace-based debugging tool that emphasizes viewing executed lines in temporal order, contrasting with traditional snapshot-based debuggers.
Findings
Preliminary results suggest improved hypothesis generation.
Design challenges include managing large trace data.
The approach offers a different perspective on program exploration.
Abstract
Programmers often use an iterative process of hypothesis generation ("perhaps this function is called twice?") and hypothesis testing ("let's count how many times this breakpoint fires") to understand the behavior of unfamiliar or malfunctioning software. Existing debugging tools are much better suited to testing hypotheses than to generating them. Step debuggers, for example, present isolated snapshots of the program's state, leaving it to the programmer to mentally reconstruct the evolution of that state over time. We advocate for a different approach: building a debugging and program-exploration tool around a *trace*, or complete history, of the program's execution. Our key claim is that the user should see every line *as executed* (in time order) rather than *as written* (in syntax order). We discuss design choices, preliminary results, and interesting challenges.
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
