Hacker News Reader

Comment by lacker | Hacker News Reader

Bah, sprinkling printf statements is a quality debugging technique. Sometimes everything really is a nail.

It seems to me that there are two schools of thought: one school which uses debuggers, the other school which uses printf statements and equivalents. Neither schools are absolutely false.

A third school that does both, based on the circumstances.

Exactly! I’ve dealt with multiple real-time embedded platforms that have a log output channel that is waaay more convenient to use via printfs than hooking up a whole debug apparatus.

I was once told a quote (original unknown, so any butchering is mine) something " when I was a young programmer, I relied on print statements to debug. When I learned more, I used a debugger, and when I learned even more, I used print statements"

I always took that to mean dogma was no substitute for results, so I use whichever works better for the problem at hand. (Or at least try to - often this means trying to notice when one way isn't working well and being willing to switch, but that means I was doing the worse choice for a while)

Though I've had the super rare occasion where the bug actually IS the code behind the print function, usually in experimental PL/OS stuff. There's a sort of turtles all the way down feeling the first time it happens.

Gotten bit by that before in Ruby, which attempted to pretty print objects by recursively enumerating their properties and printing them. One mutually recursive data structure later...

Well gdb is pretty hard to use. I learned how to step through programs recently but I'm still not confident using it. The fact that printing variables is still the quickest and easiest way to gain insight into a running program's state speaks volumes.

To use gdb, I have to recompile all code with -g, run gdb, set up breakpoints and variable printing, run the program in gdb and then slowly step through it.

Alternatively, I can just write this somewhere:

  fprintf(stderr, "i = %d\n", i);

Agreed — if you're strategic about it, you cut in half the space in which the bug could be hiding each time you add a printf and re-execute.

There's times I use the debugger and times I just print to the console. It really, really depends on the situation. Not to mention setting the logging level to DEBUG is basically the same as just a bunch of printfs and it's many times the best way to debug issues in production.

To say printf is not a "quality debugging technique" is just false.

You ever seen those bugs, where adding a printf makes the bug disappear?

Have you ever seen those bugs where attaching a debugger made the bug disappear?

Heh. Sounds like race conditions. That or your code is possessed, which I've had happen too.

My personal favorite is programs that seem non-deterministic. Different errors/results for different executions.

Reply on news.ycombinator.com