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

The unreasonable effectiveness of print debugging

buttondown.email

Post reply on HN
Print view View original

351–360 of 366 posts

Re: The unreasonable effectiveness of print debugging

#351

Post by adam_arthur »

nottorp wrote: post #344
adam_arthur wrote: post #144

I've never understood print debugging, at least in a web dev/nodejs context. I don't begrudge people having their own approach to things, but almost universally when I see people use print debugging they seem to take quite a bit longer than just break pointing at the problem area. If your code is in an unexpected state, it's much easier to hit a breakpoint, examine local values, and then backstep through the call sta…

> almost universally when I see people use print debugging they seem to take quite a bit longer than just break pointing at the problem area. Could it be... because they don't know where the problem area is yet? Which is what the original article and most comments in favor of print debugging say.

How can they not know? If you see unexpected behavior in some subsystem, it should be easy to pinpoint.

e.g. in a UI context, timeline shows wrong data. Start there and work backwards.

I can only imagine it's hard to pinpoint if the code is not factored well.

Re: The unreasonable effectiveness of print debugging

#352

Post by pjmlp »

CJefferson wrote: post #346
nomel wrote: post #306

Earlier quoted context omitted.

Reading through the majority of this comment section, I get the impression that those who like print statements find value because they aren’t proficient with modern debuggers, rather than they find print statement valuable even though they’re proficient with debuggers.

I agree, but my feeling is, if one person is bad at using debuggers it is their fault. If (as it seems to me) most developers are bad at using debuggers, then it's probably to debugger's (and associated tooling's) fault.

For me it is the teacher's fault, given that a large majority never teaches anything related to debuggers.

So we get generations that use vim and Emacs like notepad, create Makefiles by copy-paste and barely know gdb beyond set breakpoint, run, step and continue.

Using C as example, but feel free to extrapolate to another language.

And no I am not exaggerating, this was the kind of students I would get into my lab when I spent a year as TA in 1999/2000, and naturally would have to get them up to speed into good programming practices.

Re: The unreasonable effectiveness of print debugging

#353

Post by throwaway894345 »

corty wrote: post #347
Too wrote: post #319

Earlier quoted context omitted.

Not sure what situation you are talking about. Debugging Python is as easy as right-clicking a file in Pycharm and pressing debug. Why care if it was an afterthought when it for the past decade has worked perfectly.

I care. That it has worked for the last decade only means that Python was without a working debugger for 2/3 of its existence. 1/3 of which I had to suffer from it. Also, pycharm isn't really what I would call a proper debugger yet, attaching remote running processes for example just doesn't work reliably yet and is very new anyways. Debugging embedded targets just doesn't work. Multithreading is iffy (but that's unf…

Also needing to use a particular text editor to use a decent debugger is bananas.

Re: The unreasonable effectiveness of print debugging

#355

Post by ivansavz »

Too wrote: post #322
ivansavz wrote: post #290

The Python package PySnooper is pretty good for "fancy" print debug statements: https://github.com/cool-RR/pysnooper I've caught quite a few bugs using this show-me-all-locals() approach...

Looks equivalent to python -m trace --trace, which is part of standard installation.

I did't know about this option, and I just tried it. Seems to be waaaaay more verbose, but I guess it can be tweaked/customized. I tried it on a command line script that uses google libs and still waiting for stdin to come back...

What I liked about pysnooper is the ability to snoop on a specific function and/or code block to focus on the work-in-progress section of code.

Re: The unreasonable effectiveness of print debugging

#356

Post by mumblemumble »

aszen wrote: post #265
xyzzy123 wrote: post #260

Earlier quoted context omitted.

Linus used to be against kernel debugging for the longest time. The core of his position (as I understand it) was that regularly needing a debugger is a sign that your software has "gotten away from you". You've let the software get to a state where it cannot easily be understood from the architecture and program text alone. I do think debuggers can be useful when building up comprehension - particularly of other peo…

I hold the very same opinion, interactive debugging in general should be a rare need. If it's being used too often then it points to the fact that the software has to be run in order to understand it. It's representation is not sufficient to convey it's run time behaviour. Also would like to point that dynamic languages in general require more debugging than statically typed one's since one can't be certain of the da…

I find that it's not specifically the kind of programming language, so much as the way the data is structured. Passing around big generic heterogeneous data structures makes it harder to just reason about state. That's a lot more common in dynamic languages, but I also see it happen plenty in, e.g., enterprise Java code.

In those situations, it's often just so much easier to set a breakpoint and take a peek than it is to waste brain cycles on thinking about what exactly you should even be printing in the first place.

Re: The unreasonable effectiveness of print debugging

#357

Post by [deleted] »

Too wrote: post #314
zamfi wrote: post #258

Earlier quoted context omitted.

I have. What information exactly can you get from a debugger with watchable variables and immediate mode code execution, that you can't get from print? I'm not making the argument that people shouldn't use debuggers -- obviously if there's a good one that does what you need, it'd be silly not to use it. And good debuggers are great. But what happens when you're working on a distributed system? Or multiple processes o…

Silly example i made up on the spot, but not too far from real life. I'm iterating a list of 10000+ objects with about 20 or more nested properties. Some times one of them behave strange. This function runs several times per second. Option1: Print all of them, requires rebuild, would log 200000 lines every second. Unless i wrap the print inside conditions, requiring yet another rebuild. Option2: Conditional breakpoin…

[deleted]

Re: The unreasonable effectiveness of print debugging

#358

Post by jmrm »

Personally, using a good debugger and knowing how to use have been more useful to me that anything else. I mainly code in C and C++, and Visual Studio integrated debugger and GDB are my main debuggers (depending what I'm doing).

For me is faster to double click the border of a line in VS or writing "break 123" or "break fooFunction" in GDB and stepping and watching how some values changes than adding and removing "printf" lines.

Adding some asserts are other thing. They always are good, and often necessary to find some "Heisenbugs".

In other languages I probably won't think the same, but I haven't done anything big enough outside C or C++ to give a proper opinion.

Re: The unreasonable effectiveness of print debugging

#359

Post by astura »

SPBS wrote: post #159

I feel like the author gets close to the point but fails to drive it home: step-through debugging is unbelievably cumbersome. During a typical step-through debugging session, 90% of the time is spent on lines you are completely not interested in. Oh, did you accidentally skip the important point because of how tedious it was to keep spamming step-over/step-in? Better start over again. With print debugging, you set up…

>During a typical step-through debugging session, 90% of the time is spent on lines you are completely not interested in. Oh, did you accidentally skip the important point because of how tedious it was to keep spamming step-over/step-in? Better start over again.

No offense, but this sounds like you just really need to learn how to use a debugger - This is in no way a "typical step-through debugging session." I've been a professional software developer for 16 years and I've never once in my life "spamm[ed] step-over/step-in"

>I'm still waiting for the feature where you can conditionally stop at some breakpoint -only- if some other breakpoint/watchpoint was crossed over.

This is trivial to do, place two breakpoints, disable one. When the breakpoint is hit, enable the second (and optionally, disable the first).

Re: The unreasonable effectiveness of print debugging

#360

Post by jayd16 »

zamfi wrote: post #258
jayd16 wrote: post #208

Earlier quoted context omitted.

This is a lot of words but I wonder if you've ever worked with a debugger with watchable variables or immediate mode code execution. I find it odd you say print debugging is more flexible.

I have. What information exactly can you get from a debugger with watchable variables and immediate mode code execution, that you can't get from print? I'm not making the argument that people shouldn't use debuggers -- obviously if there's a good one that does what you need, it'd be silly not to use it. And good debuggers are great. But what happens when you're working on a distributed system? Or multiple processes o…

>What information exactly can you get from a debugger with watchable variables and immediate mode code execution, that you can't get from print?

Lots of things but an obvious example is private member info.

Post reply on HN