Live data from Hacker News

Don’t look down on print debugging

blog.startifact.com

91–100 of 164 posts

Re: Don’t look down on print debugging

#91
post #59

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…

Comparatively modern. Printf debugging is clearly a less modern tool than a fully integrated debugger, even though as you say those are decades old.

Re: Don’t look down on print debugging

#92
I'd love for someone to explain to be how you can use a debugger cross half a dozen languages. Print works on everything from forth to python. In my experience you need to learn at least one debugger per language with a whole bunch of corner cases where they are outright misleading. Has the situation magically changed in the last 10 years?

Re: Don’t look down on print debugging

#93
post #5
post #2

To me there are three requirements for me to be comfortable with a team culture of print-debugging. 1. If a breakpoint debugger exists for the stack, it should still be convenient and configured, and the programmer should have some experience using it. It's a skill/capability that needs to be in reserve. 2. The project has automatic protections against leftover statements being inadvertently merged into a major branc…

Why would debugging be a team culture thing? It's very individual in practice.

Yes, but then imagine saying on the next stand-up that you took a couple hours or a whole day on adding new NATVIS visualizers or GDB pretty-printers, and think of the reaction you'd get. Approval and interest, or eyerolls and comments on work prioritization? That is the difference between the two cultures. It matters at least because use of debuggers gets more effective with investment into support scripts and configs, in ways print-debugging doesn't.

Re: Don’t look down on print debugging

#94
post #30

I've used both print and proper debuggers plenty. I tend to lean on print debugging more these days. The thing about debuggers, in addition to often being a headache to set up, it usually seems tricky and time-consuming to get it to step to the lines you actually want to examine and skip the stuff you don't. And if you step past something but then later realize it was important, time to start over. It's often faster…

> And if you step past something but then later realize it was important, time to start over.

How can you do this using print debugging? For every print statement I add, I can add a breakpoint. Even more importantly, I can see the stack frame and know which functions led to the current one. I can inspect any and all variables in scope, and even change their values if I want to pretend that the code before was fine and proceed further.

Re: Don’t look down on print debugging

#95

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…

The thing is, in interpreted languages land print debugging has a power no debugger gives you: live debugging on your production instance.

Something is broken in prod, you cannot reproduce it in your test environment because you think it may be due to a config (some signing keys maybe) you can't check. And it looks like someone forgot to put logs around whatever is the problem.

You can either: spend multiple hours trying to reproduce and maybe find the cause. Or take 5mn, bash into one of your nodes, add some logging live and have a result right now: either you have your culprit or your hunch is false.

Re: Don’t look down on print debugging

#96

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.

[dead]

Re: Don’t look down on print debugging

#97
post #85
post #33

I agree with the title that you shouldn't look down on print debugging. You should look down on people who are slow at fixing bugs and who refuse to try tooling to be able to keep pace -- and using print statements can sometimes be a marker of this. But print debugging is just a tool and has its place, and the use of print debugging is not itself an indicator of poor developer performance. If you can find/fix bugs as…

I find the people quick at fixing bugs are even quicker at introducing new bugs.

I have the complete opposite experience. I learned how to use a debugger from the only 10x programmer I’ve ever had the pleasure of working with.

Person was a wizard at finding bugs. And they didn’t write many. My goal in code reviews was to find them from this person. I found 2 in 5 years.

Re: Don’t look down on print debugging

#98

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…

Exactly this. Nobody is looking down on print debugging. Everybody uses it. People are looking down on those that stop at print debugging and never reach for a full debugger.

It's particularly annoying on projects that are set up without considering proper debuggers, because often it's impossible or difficult to use them, e.g. if your program is started via a complicated bash script or makefile rather than directly.

Re: Don’t look down on print debugging

#99
post #72
post #59

Earlier quoted context omitted.

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.

That's a hell of an assumption to make and I don't quite understand your reasoning. Debuggers are complex, true, and often people don't understand their potential. People, however, approach learning code and associated tools from many different directions, backgrounds, assumptions, and biases. If I were to read beyond your words and guess why you're so emphatic, I sense that you're coming from a distinct background (I won't bother guessing) where this is either obscured from you or where you've been allowed to forget.

Re: Don’t look down on print debugging

#100

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…

Sometimes it's easier to add 3 printf() than to run your project under a debugger.
Post reply on HN