The unreasonable effectiveness of print debugging • Hacker News Board

Re: The unreasonable effectiveness of print debugging

#321

Post by Shikadi » Sun, Apr 25, 2021, 5:58 AM UTC

ruslan wrote: post #287

nyczomg wrote: post #278

Earlier quoted context omitted.

"Print debugging always works..." Nope, print debugging does not always work. Please stop saying that. Sure, it's often useful and often works. But go try to debug a race condition, or bug in some locking mechanism with print statements. I'll wait as you add a bunch of print statements, and then learn the harsh lesson that you are now debugging a completely different program with very different performance characteri…

You don't put printf() in critical sections, instead you collect some statistics. Once critical section is over you can freely print collected data for further analyzis. Or you can print it once a second. This simple technique works well for debugging racing conditions, performance issues (profiling), memory leaks, kernel drivers and bare-metal stuff where timing is a concern. So, yes "Print debugging always works...…

Collecting statistics can change race conditions too, it's just less likely

Re: The unreasonable effectiveness of print debugging

#322

Post by Too » Sun, Apr 25, 2021, 6:02 AM UTC

ivansavz wrote: post #290

The Python package PySnooper is pretty good for "fancy" print debug statements: https://github.com/cool-RR/pysnooper I've caught quite a few bugs using this show-me-all-locals() approach...

Looks equivalent to python -m trace --trace, which is part of standard installation.

Re: The unreasonable effectiveness of print debugging

#323

Post by elonvolo » Sun, Apr 25, 2021, 6:09 AM UTC

I wrote my own print debugging tracer. It’s now my goto for debugging most things.

https://github.com/elonvolo/logitall

Re: The unreasonable effectiveness of print debugging

#324

Post by Shikadi » Sun, Apr 25, 2021, 6:27 AM UTC

damagednoob wrote: post #105

Androider wrote: post #94

Speed of iteration beats quality of iteration. You can step through the program, reason about what's going on, tracking values as they change. But if you missed the moment, you have start again from the beginning (time traveling debuggers being rare). Or maybe you're looking at the wrong part entirely at this stage, and just wasting time. With print debugging you write a bit of code to test a hypothesis. Then you run…

> Speed of iteration beats quality of iteration. That's especially true if you're doing some form of TDD/unit testing. With IntelliJ, I can easily set it to watch for changes and cycle one unit test while I make changes. If something weird happens I can just drop a printf in there, understand and rectify the issue, then take it out. Much faster than step through debugging.

Good for simple stuff, but if you find yourself changing your print statements over and over, a breakpoint probably would have been faster

Re: The unreasonable effectiveness of print debugging

#325

Post by Shikadi » Sun, Apr 25, 2021, 6:33 AM UTC

bsder wrote: post #226

wodny wrote: post #209

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed. For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from mul…

Actually, using the UART interface to send text breadcrumbs out the port is a standard technique in embedded, too ... The article hits the point of print debugging, you get to see the backward in time . By the time you hit "the problem", the pointer is NULL, the memory is trashed, the system is deadlocked, etc. You need to reason about how you got there. There is a reason why the next step up from basic debugging emb…

Memory watches let you see exactly when the pointer becomes null, and the call stack. In that particular case, the debugger is much faster and easier. Not saying print debugging is useless, but I do find many of the arguments in these comments seem to think the primary feature of a debugger is to step through code

Re: The unreasonable effectiveness of print debugging

#326

Post by invalidname » Sun, Apr 25, 2021, 6:42 AM UTC

You can already do print debugging in runtime using tools such as Googles stack driver, Lightrun and Rookout (probably others too). These tools let you inject new logs into your running server so you can do print debugging without redeploying a cluster. Pretty darn cool.

They also let you place a breakpoint which doesn't stop execution so you can get a stack trace, variable states etc. without the pain.

Re: The unreasonable effectiveness of print debugging

#327

Post by pjmlp » Sun, Apr 25, 2021, 6:43 AM UTC

nomel wrote: post #306

formerly_proven wrote: post #125

Earlier quoted context omitted.

Breaking is just the default behavior when a breakpoint is hit, you can generally attach whatever behavior / conditions you want using the debugger's scripting language.

Reading through the majority of this comment section, I get the impression that those who like print statements find value because they aren’t proficient with modern debuggers, rather than they find print statement valuable even though they’re proficient with debuggers.

I once saw an interview with Visual Studio members that one reason why they started doing talks about how to use the debugger was the continuous set of requests for features that Visual Studio does almost since it exists.

Same applies to other debuggers.

It is not only the debuggers, but also OS and language runtime tracing facilities like DTrace, eBPF, ETW, JFR, ....

Many devs aren't 10x because of QI, rather because they learn and make use of the tools available to increase knowledge about the platform.

Re: The unreasonable effectiveness of print debugging

#328

Post by neonological » Sun, Apr 25, 2021, 7:02 AM UTC

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…

There's another methodology that Brian and Rob Pike miss.

Rather then stepping through a program. Add breakpoints and just step from breakpoint to breakpoint.

With a good IDE, adding a breakpoint and hitting a shortcut key is faster than a print statement and on the GUI IDE your debugging sessions are not transient.

The only time their advice makes sense to me is when I'm in an environment without a gui. Even then jetbrains has a "ssh full remote mode." However at my company I have found that this feature doesn't work under Nix (nix-shell) so we all just use print statements.

Re: The unreasonable effectiveness of print debugging

#329

Post by roca » Sun, Apr 25, 2021, 7:03 AM UTC

iudqnolq wrote: post #316

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

Use up your free sessions and if you want to use it more, email us at inquiries@pernos.co and we'll work something out.

Thanks for the cargo-rr crate, that looks nice.

Re: The unreasonable effectiveness of print debugging

#330

Post by yongjik » Sun, Apr 25, 2021, 7:15 AM UTC

I find it mildly disturbing that so many comments are saying "But breakpoints!"

One would assume that anybody who used a debugger for more than a day knows about breakpoints. TFA isn't saying you have to step through every line in a debugger.

It's saying that, even if you employ your amazing debugging skill to find exactly the point you want to look at, you will only be looking at that exact point in execution, and not other points at the same time. Sure, it will be a very detailed representation of that particular point, which can be extremely handy, but sometimes you want to look at a hundred different points in execution, at once. That's when printf comes handy - you just need a large monitor (or a small font and good eyes).