Don’t look down on print debugging • Hacker News Board

Re: Don’t look down on print debugging

#71

Post by HPsquared » Sat, Nov 23, 2024, 2:36 PM UTC

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…

Similar vibe to showing office workers how to use Vlookup in Excel. Or fields in Word.

Re: Don’t look down on print debugging

#72

Post by llm_trw » Sat, Nov 23, 2024, 2:36 PM UTC

_0ffh wrote: post #59

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…

It got put in vs code so mediocre developers can finally use it. Like all things they cargo cult it because they don't know how to use it properly.

Re: Don’t look down on print debugging

#73

Post by Al-Khwarizmi » Sat, Nov 23, 2024, 2:36 PM UTC

I'm a CS professor teaching some programming courses. I always make an effort to teach my students how to use a debugger and encourage them to use it, because otherwise they will not even try (print debugging comes naturally, while using the debugger requires more effort). I want them to master it so they can make conscious decisions about what to use.

Then, when I code myself, I use print debugging like 99.9% of the time :D I have the feeling that, for me, the debugger tends to be not worth the effort. If the bug is very simple, print debugging will do the job fast so the debugger would make me waste time. If the bug is very complex, it can be difficult to know where to set the breakpoints, etc. in the debugger (let alone if there's concurrency involved). There is a middle ground where it can be worth it but for me, it's infrequent enough that it doesn't seem worth the effort to spend time making the decision on whether to use the debugger or not. So I just don't use it except once in a blue moon.

I'm aware this can be very personal, though, hence my tries to have my students get some practice with the debugger.

Re: Don’t look down on print debugging

#74

Post by nickcw » Sat, Nov 23, 2024, 2:36 PM UTC

Debugging with print has one feature that debuggers will never match. You can send the binary or code with print/log statements to someone else who is experiencing the problem and get them to run it.

Often I have to debug bugs I can't reproduce. If method 1 - staring at the code - doesn't work, then it's add print/log statements and send it to the user to test. Repeat until you can reproduce the bug yourself or you fixed it.

Re: Don’t look down on print debugging

#75

Post by mark_undoio » Sat, Nov 23, 2024, 2:37 PM UTC

lolinder wrote: post #32

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 find that which tools I need changes immensely depending on what kinds of projects I'm working on. When debugging parsers for my toy programming languages print debugging is less helpful and I make heavy use of all the debug tools you mention. The same goes for most types of business logic—writing a test and stepping through it in the debugger is usually the way to go. But when troubleshooting odd behavior in a com…

Have you ever been able to try https://replay.io time travel debugging as an alternative to conventional logging?

Last time I tried it you were able to add logging statements "after the fact" (i.e. after reproducing the bug) and see what they would have printed. I believe they also have the ability to act like a conventional debugger.

I think they're changing some aspects of their business model but the core record / replay tech is really cool.

Re: Don’t look down on print debugging

#76

Post by scotty79 » Sat, Nov 23, 2024, 2:37 PM UTC

david-gpu wrote: post #31

If a good debugger is available, it is a great tool to have. But it is just one out of many tools. Some are more effective than others in different situations. For example, I rarely used a debugger in my career as an Android driver developer (mostly C), for several reasons. 1. My first step when debugging is looking at the code to build working hypotheses of what sort of issues could be causing the incorrect behavior…

There are no good debuggers. They all lack a simple feature of what was the value of given watch in all subsequent calls and in context of values of other watches.

Re: Don’t look down on print debugging

#77

Post by llm_nerd » Sat, Nov 23, 2024, 2:37 PM UTC

d0mine wrote: post #55

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 mode…

You should consider performance/efficiency at all stages. And that consideration should be based on an informed feedback loop where assumptions are validated and proven empirically. What developers think are performance patterns often wildly diverges from reality.

The scenario I gave is when there are performance problems with a developed project (you know -- where a profiler is actually usable, after they already decided on an approach and implemented code) and the developer is effectively guessing at the issues, doing iterative optimize-this-part then run and see if it's fixed pattern. This is folly 100% of the time. Yet it's a common pattern.

Re: Don’t look down on print debugging

#78

Post by mark_undoio » Sat, Nov 23, 2024, 2:39 PM UTC

nickcw wrote: post #74

Debugging with print has one feature that debuggers will never match. You can send the binary or code with print/log statements to someone else who is experiencing the problem and get them to run it. Often I have to debug bugs I can't reproduce. If method 1 - staring at the code - doesn't work, then it's add print/log statements and send it to the user to test. Repeat until you can reproduce the bug yourself or you f…

You can do something equivalent with time travel debugging since you can get the user with the problem to record, then ship you back a recording (or, if they don't want to, send them a debugger script to extract the logging you want).

Re: Don’t look down on print debugging

#79

Post by scotty79 » Sat, Nov 23, 2024, 2:39 PM UTC

Debuggers present you a single moment of execution but print debugging presents you the entire history of execution of relevant fragment all at once.

Create a debugger that has easily accessible history of execution and we can talk.

Re: Don’t look down on print debugging

#80

Post by macNchz » Sat, Nov 23, 2024, 2:41 PM UTC

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’ve definitely seen an undercurrent of “I don’t need the crutch of a debugger” sort of attitudes online over the years, never really made sense to me. It can be painful pairing with someone who keeps adding print statements one at a time and repeating the 15 step process to get to them when they could have put in a breakpoint right out of the gate.

I still print stuff plenty, but when the source of an issue is not immediately obvious I’m reaching for the debugger asap.