Tracers for debugging and program exploration

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.