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

Printf debugging is ok

polymonster.co.uk

Post reply on HN
Print view View original

51–60 of 152 posts

Re: Printf debugging is ok

#51

Post by chrsig »

nxobject wrote: post #50
chrsig wrote: post #19

Earlier quoted context omitted.

eternal september; people new people are continually learning new strategies. You're correct, the real issue comes down to 1. making sure those printf statements don't wind up in prod, spilling potentially sensitive data or corrupting a data stream 2. making sure that non-printf tooling is built so that only printf debugging isn't used We tend to get caught up in false dichotomies.

Re 1: the recent iTerm2 fracas. Yikes. https://news.ycombinator.com/item?id=42579472

ouch, i didn't even know about that

Re: Printf debugging is ok

#52

Post by eru »

kentonv wrote: post #49

If you have a reproducible test case that runs reasonably quickly, then I think printf debugging is usually just as good as a "real" debugger, and a lot easier. I typically have my test output log open in one editor frame. I make a change to the code in another frame, save it, my build system immediately re-runs the test, and the test log immediately refreshes. So when the test isn't working, I just keep adding print…

> BUT... this is all contingent on having fast-running automated tests that can reproduce your bugs. But you should have that anyway.

Ideally, yes. But for many bugs, getting to a reproduction is already more than half the battle. And a debugger can help you with that.

Re: Printf debugging is ok

#53

Post by mvdtnz »

We literally just saw a case[0] where an application (iterm2) mistakenly left verbose logging on in a component of a production build and logged sensitive console contents to connected hosts.

Are you diligent enough to remove your sensitive logging/printf statements EVERY time, for the rest of your career? Or should you make a habit of doing things properly from day one?

0 https://news.ycombinator.com/item?id=42579472

Re: Printf debugging is ok

#54

Post by omgJustTest »

An interesting note: printf'ing a variable can sometimes alter how a variable is cached. This is a particularly useful fact in memory locations that can change as a result of hardware operations (like a change of a status bit by a hardware element).

printf'ing effectively enforces a similar condition to `volatile` on the underlying memory segment when it is read.

One can encounter tersely written code that works perfectly with printf statements, but status bits never get "updated" (CPU cache purged) without the printf and hangs the program.

Re: Printf debugging is ok

#55

Post by binary_slinger »

Languages like Python and Java could benefit greatly from adopting the kind of powerful console logging you see in browsers. The ability to inspect objects by simply logging their pointers is incredibly useful for debugging and understanding program state.

Re: Printf debugging is ok

#56

Post by tliltocatl »

invalidname wrote: post #4

Counterpoint: nope. Logging is great for long term issue resolution. There's tracepoints/logpoints which let you refine the debugging experience in runtime without accidentally committing prints to the repo. There are specific types of projects that are very hard to debug (I'm working on one right now), that's a valid exception but it also indicates something that should be fixed in our stack. Print debugging is a ha…

If your code is connected to some external factory, it's impossible to pause on a breakpoint without breaking everything. And no, "just mock it" doesn't work if you have no idea on how the factory actually behaves. Printf is good because it doesn't messes up timing.

Re: Printf debugging is ok

#57

Post by invalidname »

tliltocatl wrote: post #56
invalidname wrote: post #4

Counterpoint: nope. Logging is great for long term issue resolution. There's tracepoints/logpoints which let you refine the debugging experience in runtime without accidentally committing prints to the repo. There are specific types of projects that are very hard to debug (I'm working on one right now), that's a valid exception but it also indicates something that should be fixed in our stack. Print debugging is a ha…

If your code is connected to some external factory, it's impossible to pause on a breakpoint without breaking everything. And no, "just mock it" doesn't work if you have no idea on how the factory actually behaves. Printf is good because it doesn't messes up timing.

I suggest re-reading my comment and learning about tracepoints/logpoints.

Your comment highlights my exact problem with print debugging... You just aren't aware of the tools available to you and you reach to the rusty old broken hammer.

Re: Printf debugging is ok

#59

Post by __MatrixMan__ »

jclulow wrote: post #38
skissane wrote: post #26

Earlier quoted context omitted.

> 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. Anoth…

If I'm looking for something and can't find it despite all signs pointing to it being nearby, I'll try to continue looking while upside down. It's often helpful for I think the same reasons that you describe.

One time, I was looking for a set of keys which had been tossed over the aisle partition in a grocery story and promptly disappeared. We tore that place apart and still couldn't find them. So I was laying on my back on the aisle floor so I could see the search area with my head upside down, and there they were. They had bounced and were hanging from the bottom of one of the shelves.

When in doubt, do something weird.

Re: Printf debugging is ok

#60

Post by whatevertrevor »

kentonv wrote: post #49

If you have a reproducible test case that runs reasonably quickly, then I think printf debugging is usually just as good as a "real" debugger, and a lot easier. I typically have my test output log open in one editor frame. I make a change to the code in another frame, save it, my build system immediately re-runs the test, and the test log immediately refreshes. So when the test isn't working, I just keep adding print…

> Most importantly, though, this sort of debugging is performed using the same language and user interface I use all day to write code in the first place, so I don't have to spend time trying to remember how to do stuff in a debugger... it's just code.

Absolutely! Running a commandline debugger adds additional context I have to keep in my head (syntax for all the commands, output format etc), that actively competes with context required to debug my code. Printfs work just fine without incurring that penalty, granted this argument applies less to IDE debuggers because their UX is usually intuitive.

Post reply on HN