Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unreasonable effectiveness of print debugging

buttondown.email

Post reply on HN
Print view View original

311–320 of 366 posts

Re: The unreasonable effectiveness of print debugging

#311

Post by porknubbins »

wrycoder wrote: post #268
xyzzy123 wrote: post #260

Earlier quoted context omitted.

Linus used to be against kernel debugging for the longest time. The core of his position (as I understand it) was that regularly needing a debugger is a sign that your software has "gotten away from you". You've let the software get to a state where it cannot easily be understood from the architecture and program text alone. I do think debuggers can be useful when building up comprehension - particularly of other peo…

Agreed. The only time I've found a debugger useful is when the print statements aren't immediately giving clarity, and cognitive dissonance is settling in.

I think its the same as cognitive dissonance but I always find debuggers help when my code appears to be doing something impossible- like I’ll be thinking how could if(true) ever fail then remember oh this whole function isn’t even getting called and I had fixated on the wrong place. Debuggers will sort it out faster than a bunch of print statements.

Re: The unreasonable effectiveness of print debugging

#312

Post by bc4m »

ReactiveJelly wrote: post #291
dmitryminkovsky wrote: post #242

Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…

> we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Uh, me too. That's why I don't single-step through huge chunks of a program. I use code breakpoints.

I'm getting the impression a lot of people don't know basic debugger features like "continue" or setting breakpoints while paused at a breakpoint.

Re: The unreasonable effectiveness of print debugging

#313

Post by iudqnolq »

cratermoon wrote: post #191
dragonwriter wrote: post #115

Earlier quoted context omitted.

> And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved. The problem is that the two print statements will only catch the bug if they are the right two, based on a correct hypothesis of what the bug is. Which, with a debugger, won’t require stepping, but setting two breakpoints, doing a run-to-breakpoint, and insp…

But with print statements if the first place I put them doesn't work, I can start doing bisects and quickly find the right place to print. As you note, debugger breakpoints aren't magically better than print statements when I'm investigating a hypothesis – I'm no more likely to put them the right place than I would have put print statements. And then there's a class of problems that neither debugger nor print stateme…

I can bisect faster with breakpoints. Plus with a time traveling debugger like rr the the time is further reduced.

Re: The unreasonable effectiveness of print debugging

#314

Post by Too »

zamfi wrote: post #258
jayd16 wrote: post #208

Earlier quoted context omitted.

This is a lot of words but I wonder if you've ever worked with a debugger with watchable variables or immediate mode code execution. I find it odd you say print debugging is more flexible.

I have. What information exactly can you get from a debugger with watchable variables and immediate mode code execution, that you can't get from print? I'm not making the argument that people shouldn't use debuggers -- obviously if there's a good one that does what you need, it'd be silly not to use it. And good debuggers are great. But what happens when you're working on a distributed system? Or multiple processes o…

Silly example i made up on the spot, but not too far from real life. I'm iterating a list of 10000+ objects with about 20 or more nested properties. Some times one of them behave strange. This function runs several times per second.

Option1: Print all of them, requires rebuild, would log 200000 lines every second. Unless i wrap the print inside conditions, requiring yet another rebuild.

Option2: Conditional breakpoint: user[i].department.balance In short, a debugger allows you to see all state of the program at once, and you can retroactivelly choose what is relevant. As opposed to printf where you must select upfront. Maybe even more importantly it's lacking stack traces, unless you add a log and request-id at every function-enter/exit.

There is also the case of third party code which you can't edit to add printf to. Many environments usually by default give you pretty good context of the symbol names or even complete source code which you can step through (except c++ land where you'd need a debug-build of the lib, which isn't impossible either).

Re: The unreasonable effectiveness of print debugging

#315

Post by bc4m »

CJefferson wrote: post #23

Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…

This is the only argument for print debugging I can understand. Given the debugger experience I've had at every job in the last 10 years (IDE-driven, set breakpoints in editor, inspect state visually) it's mind-boggling that anyone thinks print statements are superior, but getting that experience can be frustrating depending on your tools and environment.

FWIW my experience debugging Python in VS Code required no setup and I've encountered zero issues.

Re: The unreasonable effectiveness of print debugging

#316

Post by iudqnolq »

roca wrote: post #255

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). I think it's important for people to understand that the superiority of print debugging is contingent and, for many developers, will not persist. Record-and-replay debuggers like rr [0] (dis…

Thank you! I've recently started learning how to use rr and it's been amazing so far. I've written a tiny wrapper to parse cargo's output and run rr on the appropriate binary to reduce the friction a little[1]

I'd love to use pernosco, but it's too expensive for me. Do you have any sort of student discount?

[1]: https://crates.io/crates/cargo-rr

Re: The unreasonable effectiveness of print debugging

#317

Post by bc4m »

SPBS wrote: post #159

I feel like the author gets close to the point but fails to drive it home: step-through debugging is unbelievably cumbersome. During a typical step-through debugging session, 90% of the time is spent on lines you are completely not interested in. Oh, did you accidentally skip the important point because of how tedious it was to keep spamming step-over/step-in? Better start over again. With print debugging, you set up…

Why would I spend any time stepping through lines I'm not interested in? I set breakpoints on the important parts and let the program run until a breakpoint is hit.

I stop at a breakpoint only after another breakpoint is hit all the time. You set the first breakpoint and run the program. It gets hit and pauses, you set the second breakpoint, then resume.

I'm just not getting how print debugging is the better experience.

Re: The unreasonable effectiveness of print debugging

#318

Post by euske »

Personally the biggest obstacle of using a debugger is that it cannot be automated easily. You have to be present when it's triggered. You have to navigate it manually. When the program crashes again, you have to repeat the process. I know some debuggers can be automated but then you'll have to debug the debugger script.

Logging is much nicer because you can turn the exploration process into a text analysis problem. Logs can be searched, stored and compared. For me, sifting the log is much easier.

Whenever I try to write a medium-sized program for a serious kind of purpose, the first thing I do is to set up a nice and reliable logging system. This is the decision that you won't regret for the rest of development.

I would argue that the use case of a debugger is much narrower than logging/printf debugging.

Re: The unreasonable effectiveness of print debugging

#319

Post by Too »

corty wrote: post #132
throwaway894345 wrote: post #77

Earlier quoted context omitted.

I can believe there is value in learning a debugger, but debuggers could stand to improve significantly. Debugger UX is almost universally awful and per the parent it’s often difficult to get one up and running. Moreover, if you do your “print debugging” with log statements of the appropriate level, they can be useful in production which is perhaps the biggest value.

Also, in almost all languages debuggers are an afterthought. Take e.g. the situation with Golang, Haskell or Python. Either there is no useful debugger or there is one, but it came late and still cannot debug everything the language does.

Not sure what situation you are talking about. Debugging Python is as easy as right-clicking a file in Pycharm and pressing debug. Why care if it was an afterthought when it for the past decade has worked perfectly.

Re: The unreasonable effectiveness of print debugging

#320

Post by [deleted] »

le-mark wrote: post #31
CJefferson wrote: post #23

Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…

I’m sorry but this is just ignorance, learning to use the debugger for the platform at hand is a basic skill every developer should master. So many times have seen developers use the debugger to troubleshoot and fixed issues and been perceived as a “ninja” (despise that term but that was the effect) because they knew how to use the debugger. I mean yeah keep printing lines, and keep being out performed by your debugg…

[deleted]
Post reply on HN