Live data from Hacker News

Printf debugging is ok

polymonster.co.uk

31–40 of 152 posts

Re: Printf debugging is ok

#31
post #5

I've gotten an OS to run on a new platform with a debugging tool portfolio consisting of a handful of LEDs and a pushbutton. After getting to the point where I could printf() to the console felt like more than anyone could ever ask for. Anecdote aside, it certainly doesn't hurt to be able to debug things without a debugger if it comes to that.

Since most of my work is in distributed systems, I find the advice to never printf downright laughable.

"Oh sure, lemme just set a breakpoint on this network service. Hm... Looks like my error is 'request timed out', how strange."

That having been said: there are some very clever solutions in cloud-land for "printf" debugging. (Edit: forgot this changed names) Snapshot Debugger (https://github.com/GoogleCloudPlatform/snapshot-debugger) can set up a system where some percentage of your instances are run in a breakpointed mode, and for some percentage of requests passing through the service, they can log relevant state. You can change what you're tracking in realtime by adding listeners in the source code view. Very slick.

Re: Printf debugging is ok

#32

I have a very specific technical (UX) reason for using `print()` to debug sometimes . In VS Code, if you want to run debugger with arguments (especially for CLI programs), you have to put these arguments in launch.json and then run the debugger. This is often tedious to do, because I usually have typed these arguments and tested in terminal before, and now I have to convert them into json format, which is annoying. T…

I have the same issue. The tool I’m working on has a CLI with multiple subcommands. So I just added a REPL subcommand to my CLI. That way, I can start the CLI REPL in VSCode debug and then paste in the subcommand/arguments I want to debug.

Re: Printf debugging is ok

#33

Earlier quoted context omitted.

9 fingers... Not 10, 9.

I use both my thumbs on the spacebar to assert dominance on every word. But now I'm curious, which thumb do most people use on a keyboard?

My spacebar(s) are very smooth and shiny on the right compared to left.

Re: Printf debugging is ok

#34
The main advantage of printf is that it's usually just there, one line of code away. Setting up a useful debugger session can be much more involved (it varies widely depending on what you're working on), so my ADHD mind will absolutely try to get away with printf first if it's possible. Sometimes it ends up being counter-productive, and you just learn to recognize when to bother with experience.

That said, there are some contexts where this is reversed - printing something useful without affecting the debugged code may actually be more involved than, say, attaching a JTAG probe and stepping through with a debugger. Though sometimes both of those are a luxury you can't afford, so you better be able to manage without them anyway (and this may happen to you regardless of whether you're working on low-level hardware bring-up or some shiny new JavaScript framework).

Re: Printf debugging is ok

#35
It’s shocking how many people never use a debugger. Like sure printf debugging is good enough sometimes. But never? That’s wild.

Honestly I think attaching a debugger should be the first debugging tool you reach for. Sometimes printf debugging is required. Sometimes printf debugging is even better. But a debugger should always be the tool of first choice.

And if your setup makes it difficult to attach a debugger then you should re-evaluate your setup. I definitely jump through hoops to make sure that all the components can be run locally so I can debug. Sure you’ll have some “only in production” type bugs. But the more bugs you can trivially debug locally the better.

Of course I also primarily write C++ code. If you’re stuck with JavaScript you maybe the calculus is different. I wouldn’t know.

Re: Printf debugging is ok

#36
I can't imagine what it's like to be so passionate about something that works, and it's not some philosophical/moral issue, just -- real programmers use X?

I use vim, IDEs, debuggers, printf debugging, whatever works. A tool is a tool. I guess my holier-than-thou position is against the idea that there's one right way to do anything.

Re: Printf debugging is ok

#38
post #3

Whatever works so I can fix it and be home on time. I will even print (in paper) the code and step through it with a pen. Again, whatever works. Also, will we ever move forward from these sort of discussions? Back when I was a mechanic no one argued about basics troubleshooting strategies. We just aimed to learn them and apply them all (as necessary).

> Whatever works so I can fix it and be home on time. I will even print (in paper) the code and step through it with a pen. I’ve found before that sometimes I can’t see what’s wrong with the code on my screen but I can when I print it out. I think the printed page activates different regions of the brain compared to looking at a computer screen

You should try other things that force the brain to begin interpreting something again as new input; e.g., I have found success with changing the font, or the colour scheme, or looking at a diff rendition of a change, or looking at the file with less(1), or even reading the thing in reverse order, provoking a similarly new context where I see stuff I won't have seen staring at the editor for an hour previously. Another thing printing usually induces is that you simply stop looking at it for at least a few minutes before looking again, and a break often helps too!

Printing is obviously fine if you like doing that, but I've found there are lots of ways to shake yourself loose and more thoroughly review your own writing.

Re: Printf debugging is ok

#40

It’s shocking how many people never use a debugger. Like sure printf debugging is good enough sometimes. But never? That’s wild . Honestly I think attaching a debugger should be the first debugging tool you reach for. Sometimes printf debugging is required. Sometimes printf debugging is even better. But a debugger should always be the tool of first choice. And if your setup makes it difficult to attach a debugger the…

To be frank, I actually find debugger to rarely be useful. When it is useful, it is super useful - but those occasions aren't that numerous, so I can totally believe that many people may get away without learning how to use it. It feels like 90% of my time in gdb is reading backtraces after segfaults, which I wouldn't really consider to be a use of a debugger. I'm still glad I can use it for the other 10%, but it's just 10%.
Post reply on HN