Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Tuesday 27 April 2021

Print Debugging Should Go Away

This is based on a comment I left on HN.

Many people prefer print debugging over interactive debugging tools. Some of them seem to have concluded that the superiority of print debugging is some kind of eternal natural law. It isn't: almost all the reasons people use print debugging can be overcome by improving debuggers — and to some extent already have been. (In the words of William Gibson, the future is already here, it's just not evenly distributed yet). The superiority of print debugging is contingent and, for most developers, it will end at some point (or it has already ended and they don't know it.)

Record-and-replay debuggers like rr (disclaimer: I initiated it and help maintain it), Undo, TTD, replay.io, etc address one set of problems with interactive debuggers. You don't have to stop the program to debug it; you can record a complete run, and debug it later. You can record the program many times until it fails and debug only the execution that failed until you understand the failure. You can record the program running in a far-off machine, extract the recording and debug it wherever you want.

Pernosco (disclaimer: also my baby) and other omniscient debuggers go much further. Fans of print debugging observe that "step debuggers" (even record-and-replay step debuggers, like rr) only show you one point in time, and this is limiting. They are absolutely right. Omniscient debuggers have fast access to all program states and can show you at a glance how program state changes over time. One of our primary goals in Pernosco (mostly achieved, I think) is that developers should never feel the need to "step" to build up a mental picture of how program state evolves over time. One way we do this is by supporting a form of "interactive print debugging":

Once you buy into omniscient debugging a world of riches opens to you. For example omniscient debuggers like Pernosco let you track dataflow backwards in time, a debugging superpower print debugging can't touch.

There are many reasons why print debugging is still the best option for many developers. rr, Pernosco and similar tools can't even be used at all in many contexts. However, most of the limitations of these tools (programming languages, operating systems, hardware platforms, overhead) could be mitigated with sufficient investment in engineering work and a modicum of support from platform vendors. It's important to keep in mind that the level of investment in these tools to date has been incredibly low, basically just a handful of startups and destitute open source projects. If the software industry took debugging seriously — instead of just grumbling about the tools and reverting to print debugging (or, at best, building a polished implementation of the features debuggers have had since the 1980s) — and invested accordingly we could make enormous strides, and not many people would feel the need to resort to print debugging.

Comments

Anonymous
Is there a way to do replay debugging for python?
Zac
The best Python implementation I know of is https://pytrace.com/
Unknown
Try debugging in LSL (Linden Scripting Language).
Unknown
Try debugging in LSL (Linden Scripting Language).
Unknown
Try debugging in LSL (Linden Scripting Language).
Unknown
Try debugging in LSL (Linden Scripting Language).
smitty1e
https://pytrace.com/ beams one's code off to wherever? Seems a non-starter for all but the most trivial code.
Ineiti
Most of the programming environments I'm working on have very poor debugging support. Choosing between spending hours to set up the debugger and just adding a `println` mostly lets me do the latter. Also, I never got a debugger running for distributed systems - you'd have to be able to keep all the servers under one debugger, and then somehow debug what's happening as messages go back and forth. The closest I found for distributed systems is stuff like Honeycomb, but it's still only an advanced print debugging tool... Of course the question is: how do you propose to debug distributed systems?
Ashish Narmen
I am a test engineer, and I used interactive debugging tools in the past. However, of late, programming languages that I use for work have limited support. Most of the developers I work with have never used any interactive debugging tools and rely solely on print debugging. One of them almost fell off his chair when I mentioned that the Visual Studio debugger had features to edit code and step back in real-time. Then, there are influential authors and experts like Bob Martin who are against using debuggers. (https://twitter.com/unclebobmartin/status/1196057403449659393?lang=en)
Unknown
As far as pytrace.com "beams one's code off to wherever", according to https://github.com/gleb-sevruk/pycrunch-trace , "In case if you want to run UI locally, instead of using hosted version:" you can run your own copy of the UI with this code: https://github.com/gleb-sevruk/pycrunch-tracing-webui
Josh Cogliati
I would like to echo Ineiti's question, how do you propose to debug distributed systems? (Even getting print debugging working on them can be a pain since you have multiple programming languages running on multiple hosts in multiple processes.)