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

Don’t look down on print debugging

blog.startifact.com

Post reply on HN
Print view View original

51–60 of 164 posts

Re: Don’t look down on print debugging

#51

Post by lolinder »

TinkersW wrote: post #42
montroser wrote: post #9

Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…

For concurrency issues you don't want a debugger or printing as both are terrible for this, you want a library designed to specifically detect these issues, I have a custom one but many other people use valgrind etc.

This depends a lot on your stack. If we're talking about concurrency issues in a multi-threaded systems-level program, you're probably right and I can't speak to that. But as a web developer when I talk about concurrency issues I'm usually talking about race conditions between network requests and/or user input, and print works fine for those. The timings at fault are large enough that the microscopic overhead of print doesn't change them meaningfully.

Re: Don’t look down on print debugging

#52

Post by FartyMcFarter »

Concise argument for print debugging:

Print debugging is how you make software talk back to you. Having software do that is an obvious asset when trying to understand what it does.

There are many debugging tools (debuggers, sanitisers, prints to name a few), all of them have their place and could be the most efficient route to fixing any particular bug.

Re: Don’t look down on print debugging

#54

Post by mrkeen »

montroser wrote: post #9

Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…

This is the exact realisation that made me take a second look at FP around 10 years ago. I haven't looked back since. I certainly couldn't debug concurrency issues in imperative code when I was young and sharp, but at least I tried. Now that I'm old, if I get a concurrency issue, I'll just file a ticket and grab a coffee instead.

Re: Don’t look down on print debugging

#55

Post by d0mine »

llm_nerd wrote: post #22

While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…

Performance optimization is an excellent example of exactly the opposite. Why thinking first, creating the model of the code, to put a trace, metric, log call is better than mindless debugging. Interactive debugging has its uses but it may be less than appears at first and it encourages the wrong thing (local focus, irrelevant details). You should ask yourself first how fast the code should be and why (build the model), and only then measure. Learning happens when you get unexpected results. There is a limited utility in running profilers without a thought.

Re: Don’t look down on print debugging

#56

Post by Macha »

llm_nerd wrote: post #22

While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…

I do sometimes use print debugging despite having (in my opinion), a decent knowledge of the debuggers in the toolchains I use. Part of is that you could set a conditional breakpoint for a condition, if you know what it is, but sometimes you're just probing to see what differs from expectations, and putting every expectation into a conditional breakpoint is a pain with most debugger UIs. In theory you could use logpoints instead of print statements, but again the UI for this is often a pain compared to just typing in print. And even when you get to the breakpoint, you'll run into the dreaded "this variable has been optimised away" increasingly in modern languages, and it also doesn't give you a history of how it got there - maybe if rewind debugging was more commonly supported that would help, but it isn't.

Also suspending a thread to peek around is more likely to hide timing bugs than the extra time spent doing IO to print.

Re: Don’t look down on print debugging

#57

Post by mark_undoio »

montroser wrote: post #9

Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…

Print logging is pretty good for concurrency IMO because it doesn't stop the program and because it gives you a narrative of what happened.

If you have a time travel debugger then you can record concurrency issues without pausing the program then debug the whole history offline, so you get a similar benefit without having to choose what to log up front.

E.g. use Microsoft's WinDbg time travel integration: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

Or on Linux use rr (https://rr-project.org/) or Undo (https://undo.io - disclaimer: I work on this).

These have the advantage that you only need to repro the bug once (just record it in a loop until the bug happens) then debug at your leisure. So even rare bugs are susceptible.

rr and Undo also both have modes for provoking concurrency bugs (Chaos Mode from rr - https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo..., Thread Fuzzing from Undo - https://undo.io/resources/thread-fuzzing-wild/)

Re: Don’t look down on print debugging

#58

Post by stitched2gethr »

wkirby wrote: post #41

My only complaint about print debugging is the sheer volume of commented out console.log statements I see across code bases. Or worse, not commented out and happily logging away on prod. Seriously, leave your console open as you browse around — you’ll be astounded by the amount of debug output just rolling along on production. Delete your debug cruft!

I have a perfect solution for this, that works for me at least.

Adding a `..` to the end of a variable triggers a macro that changes `val` into something like `print("val:", val) // FIXME: REMOVE`. Then a pre-commit hook makes sure I am unable to commit lines matching this pattern.

Re: Don’t look down on print debugging

#59

Post by _0ffh »

llm_nerd wrote: post #22

While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…

Speaking from my own experience I'm not so sure that printf debuggers just have "incomplete knowledge [...] of modern debugging tools". I use printf (or the file-based equivalent, log files) quite a lot, but nobody can accuse me of not knowing good debugging environments.

Also, what's "modern" about "Walk the call stack! See the parameters and values, add watches, set conditional breakpoints"? Those are all things we had many decades ago (for some languages, at least). If anything, many modern debugging environments are fat and clunky, compared with some of the ones from way back when. What has greatly improved though are time travellers, because we didn't use to have the necessary amounts of memory lots of the time.

So please refrain from calling people with different preferences uneducated. [Ed. I retract this bit, though I think it is not unreasonable to associate lack of knowledge with lack of education (not necessarily formal education!) I don't want to quibble over semantics.]

Post reply on HN