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

71–80 of 152 posts

Re: Printf debugging is ok

#71

Post by skissane »

eru wrote: post #52
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.

> But for many bugs, getting to a reproduction is already more than half the battle.

Today I am working on a bug where a token expires after 2 hours and then we fail to request a new one instead we just keep on using the now expired one, which (of course) doesn’t work. I have a script to reproduce it but it takes 2 hours to run. It would be great if there was some configuration knob to turn down the expiry just for this test so we can reproduce it faster - but there isn’t because nobody thought of that.

Re: Printf debugging is ok

#72

Post by forrestthewoods »

fragmede wrote: post #68
forrestthewoods wrote: post #62

Earlier quoted context omitted.

GDB is a dog shit trash debugger. I keep forgetting that Linux and Mac have shit tools. I suppose if the only debugger available to me were GDB I would also prefer printf debugging! The typical modern dev loves to shit on Windows. But Visual Studio (the adult version, not VSCode) is still a best-in-class debugger. Xcode is bloated as hell but did help me last week. Linux has… poor bastards.

Has VSCode, which also runs on Mac. Does Visual Studio do time traveling yet? https://www.replay.io/ is cross-platform.

VSCode is an extremely mediocre debugger. It’s better than nothing. But it’s not great.

WinDbg has a time traveling debugger.

replay.io does not support a single language or environment that I care about.

Re: Printf debugging is ok

#73

Post by jaredsohn »

mvdtnz wrote: post #53

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=4257947…

>Are you diligent enough to remove your sensitive logging/printf statements EVERY time

Yes, when a linter is set up that fails when printf debugging is found

Re: Printf debugging is ok

#74

Post by skissane »

seanmcdirmid wrote: post #64
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…

The crashes/bugs I deal with are rarely straight down failures, they are often the 1 out of 100 runs kind, so printf debugging is the only way to go really. And I used to be big on using debuggers, but now I’m horribly out of practice.

> The crashes/bugs I deal with are rarely straight down failures, they are often the 1 out of 100 runs kind, so printf debugging is the only way to go really.

Another thing I’ve found helpful, is to write out a “system state dump” (say in JSON) to a file whenever certain errors happen. Like we had a production system that was randomly hanging and running out of DB connections. So now whenever the DB connection pool is exhausted, it dumps a JSON file to S3 listing the status of every DB connection, including the stack dump of the thread that owns it, the HTTP request that thread is serving, the user account, etc. Once we did that, it went from “we don’t understand why this application is randomly falling over” to “oh this is the thing that is consistently triggering it”

When it writes a dump, it then starts a “lockout period” in which it won’t write any further dumps even if the error reoccurs. Don’t want to make a meltdown worse by getting bogged down endlessly writing out diagnostics.

Re: Printf debugging is ok

#75

Post by atq2119 »

skissane wrote: post #71
eru wrote: post #52

Earlier quoted context omitted.

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

> But for many bugs, getting to a reproduction is already more than half the battle. Today I am working on a bug where a token expires after 2 hours and then we fail to request a new one instead we just keep on using the now expired one, which (of course) doesn’t work. I have a script to reproduce it but it takes 2 hours to run. It would be great if there was some configuration knob to turn down the expiry just for t…

Maybe it takes less than 2 hours to add such a configuration knob?

Re: Printf debugging is ok

#76

Post by atq2119 »

kadoban wrote: post #9
LordGrignard wrote: post #7

all the rest of the stuff is okay but seriously? 2 finger typing? as a programmer? you're gonna be there for AAAGES and your keyboard probably runs a sidebusiness with how long it takes you to type I know I'm stirring up shit here but there really are benefits to touch typing (I mean just think about it, using 10 fingers instead of 2 is gonna be so much faster assuming you have 10 dingers)

Touch typing is objectively better, but 2 finger is enough to have a career at programming, it's not what is going to hold you back. I'd be more concerned about RSI than speed. You _really_ don't need to type fast for programming. If you do, your tools should be helping you do boilerplate more.

The RSI thing is real. Until my late 20s I would type blindly with what I jokingly called 5 and a half fingers. But I did start to notice some strain, which is when I decided to finally teach myself "proper" touch typing. I don't think my typing got meaningfully faster, but it got smoother, and the strain went away.

Re: Printf debugging is ok

#77

Post by bee_rider »

pryelluw wrote: post #18
johnnyanmac wrote: post #11

Earlier quoted context omitted.

Based on the "lucky 10k" and the size of the internet, likely not. I'm sure if you find a mechanics enthusiast forum you will in fact find these relatively trivial arguments. It's just the nature of the beast.

I’d say programmers are taught to nitpick away at arguments by default. The nature of the code review is to verify that the code I wrote meets certain (opinions) standards. Hence nitpicking is built into the profession. Maybe one day it’ll improve. Till then, I’ll continue arguing about everything there is :-)

I wouldn’t say programmers are taught to nitpick, so much as look for non-obvious problems. The nitpicking comes as a side effect. Maybe it is cargo-culting.

Re: Printf debugging is ok

#79

Post by skissane »

atq2119 wrote: post #75
skissane wrote: post #71

Earlier quoted context omitted.

> But for many bugs, getting to a reproduction is already more than half the battle. Today I am working on a bug where a token expires after 2 hours and then we fail to request a new one instead we just keep on using the now expired one, which (of course) doesn’t work. I have a script to reproduce it but it takes 2 hours to run. It would be great if there was some configuration knob to turn down the expiry just for t…

Maybe it takes less than 2 hours to add such a configuration knob?

That’s a good idea except it is in another team’s service and I’m not very familiar with their code. But I can try

Well, the hard part isn’t actually the code change (reasonably obvious) it is deploying my own copy of their service…

Re: Printf debugging is ok

#80

Post by nejsjsjsbsb »

Do people think it is not?

The only time it is not OK is when breakpoint debugging is overall faster but you are avoiding the hassle of setting up the debugger.

Also OK: adding a console.log or print in your node modules or python package cache.

And btw splunk, datadog etc. is just printf at scale.

Post reply on HN