The Most Effective Debugging Tool

We really can do better than print statements

“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” — Brian Kernighan, co-creator of Unix

No, I don’t think so.

I think a more effective debugging tool is:

1. careful thought coupled with

2. an Interactive REPL, operating your program

3. which allows you to store, label, and access any of the thoughts & data that come up during the debugging session (even after the inspected objects leave memory)

4. coupled with judicious placement of breakpoints AND print statements which appear in the debugging data-store, and can always be searched or accessed until the debugging session is over

5. combined with visualizations of each operation

   ---

If your programming environment doesn’t have a better system, that’s okay. Most of our debugging tools are still primitive. They constantly forget previous states, they constantly lose crucial data in the debugging process. They don’t make a timeline of events obvious. How is it that putting in two breakpoints is somehow WORSE than putting in two print statements. A breakpoint should be, at the very least, an informative contextual marker on a broader timeline of your program; like a print statement, but MORE powerful.

It’s wild to me that the best judiciously constructed “timeline” of relevant events many programmers have access to is a series of print statements, rather than, perhaps, a series of samples of the state, a series of pictures, a series of explorable explanations, a series of interactive REPLs which could be strictly more powerful than print statements.

Even if we thought a series of printed strings in the terminal was the pinnacle of debugging UX, we could imagine a debugging system where print statements are “empowered”, such that we can click on any print statement in the console and instantly be pulled into a relevant exploration of the context, perhaps in a REPL.

The core point here is that a series of strings in my terminal is perhaps a simple and easy starting point for the concept of a debugging action. But there are many powerful, visualizable, learnable, beginner-friendly, expert-friendly, interactive, beautiful, and interesting debugging actions left to explore and build.

Some examples of what I’m talking about below:

---

From Bret Victor, Learnable Programming:

From Data Rabbit, Using Data Rabbit as a 'data rich' Clojure REPL Client:

Code manipulates data. To understand code, a learner must see the data, and see the effect of code on the data.
— Bret Victor, Learnable Programming