“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:
careful thought coupled with
an Interactive REPL, operating your program
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)
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
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
Great article. I've actually had this open for about a week and have re-read it a few times. Thinking about these things as I continue building an AI-driven "learn to do creative coding app" with a friend.