Hacker News new | ask | show | jobs
by bayonetz 1482 days ago
In this thread, people making all sorts of claims about print() debugging being better because of speed, efficiency, less overheard, “debuggers are too hard”, etc. on and on, but not actually providing evidence for their claim. For example, how do you know it’s faster for you? Less overheard by what comparison? Like did you give a debugger an equal and fair shot for some appreciable amount of time? I routinely probe these type of assertions from my coworkers about print()’s superiority and find that ~75% of the time, they’ve never given the debugger a fair trial or invested in understanding all it’s strengths and capabilities. ~25% of the time they’ve done a fair comparison and print() debugging is indeed the right choice for their context. Fine. Good for them! Every now and then someone takes me up on teaching them how to use a debugger effectively though and they are almost without exception, albeit begrudgingly, astounded at what they’ve been missing out on only using print().
4 comments

The problem with using debuggers is it's weakness: debuggers don't scale — they're very human centric, interactive and people are slow.

If I can produce a printf() log/trace + grep, picking out needles in concurrent haystacks is incredibly efficient. 1 in 1000 events are very detectable. Breakpoints would wedge, possibly crash, and frequently mask/alter execution.

And I say this having been "the guy who can debug anything" at a few places using debuggers, having written programmatic debuggers, and built all sorts of contraptions to debug issues as needed.

I know for a fact that print() is faster than breakpoints because debuggers take so much longer to pause and capture the heap and the stack at the breakpoints, whereas printing (or even logging) is just another line of code to run without interruption.

Also, sequential console logs are much easier to comprehend than breakpoints when you’re debugging concurrent events.

A human interacting with a debugger can not compete with error detecting code printing out exactly when the application state is invalid. A human interacting with a debugger can not debug complex interaction bugs in a distributed system. A centralised printf log can. A human interacting with a debugger can not debug real-time timing bugs. But printf can. I could go on all day but hopefully you get the picture. Debuggers are fine in certain limited scenarios. But the systems I maintain every day are way too complex for that.
I use Sentry in development and find it indispensable. I'll also use the breakpoint embed from ipython to get a shell prompt from a hotspot of trouble. But I most often use prints. They are just too easy and 95% of the time expose what I need to know to fix the problem.