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

281–290 of 366 posts

Re: The unreasonable effectiveness of print debugging

#281

Post by tiborsaas »

Swizec wrote: post #91
roenxi wrote: post #73

Probably the most interesting thing about development as a discipline is the near radio silence on how to debug. There is a decided lack of academic success in engaging with debugging as an object that can be studied. There are channels to learn about debugging as a stand-alone topic. Programmers don't often talk about debugging techniques in my experience. For something that takes up the overwhelming bulk of a devel…

Debugging is impossibly difficult to teach. It's much closer to "how to solve an escape room" than it is to "how to build X". Debugging requires deep understanding what you are doing and your system. It's different every time. And while there's a general algorithm you can follow: 1. Guess what's wrong 2. Ask "How would I prove that's wrong?" 3. Try it 4. If bug found, fix, if not go back to 1 How would you teach that…

My general approach is simply to ask: what changed?

This assumes that I'm working with an already working system, but if I'm implementing a new feature, debugging is easier since I have more flexibility to explore alternative approaches.

Re: The unreasonable effectiveness of print debugging

#282

Post by Taniwha »

bluGill wrote: post #279
nyczomg wrote: post #278

Earlier quoted context omitted.

"Print debugging always works..." Nope, print debugging does not always work. Please stop saying that. Sure, it's often useful and often works. But go try to debug a race condition, or bug in some locking mechanism with print statements. I'll wait as you add a bunch of print statements, and then learn the harsh lesson that you are now debugging a completely different program with very different performance characteri…

Debuggers don't work in the situation you described either.

Yes, my reaction entirely, I do a lot of real-time work, an interactive debugger is quite useless when stopping everything is not an option

Re: The unreasonable effectiveness of print debugging

#283

Post by zoomablemind »

dmitryminkovsky wrote: post #242

Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…

In a way, the print-debugging is a sign of 'owning' the code, when a developer is very much familiar with the structure and internal works of the project. This is akin to surgeon precisely pointing the scope and scalpel.

Add to this a need to build a debugging-enabled version of the project - an often long-running process, compared to a few edits to some 'release' build.

On the other hand, when dealing with an unfamiliar or complex and well-forgotten project, debuggers become that discovery and exploration tool that offers a wider context and potentially better situational awareness.

Of course, mix-in some concurrency and either debugging approach can equally become cumbersome without proper understanding of the project.

Re: The unreasonable effectiveness of print debugging

#284

Post by nyczomg »

bluGill wrote: post #279
nyczomg wrote: post #278

Earlier quoted context omitted.

"Print debugging always works..." Nope, print debugging does not always work. Please stop saying that. Sure, it's often useful and often works. But go try to debug a race condition, or bug in some locking mechanism with print statements. I'll wait as you add a bunch of print statements, and then learn the harsh lesson that you are now debugging a completely different program with very different performance characteri…

Debuggers don't work in the situation you described either.

Where did I say that they did work?

Re: The unreasonable effectiveness of print debugging

#285

Post by fake-name »

CJefferson wrote: post #71
1337shadow wrote: post #42

Earlier quoted context omitted.

What Python debuggers you are talking about? have you tried the built-in CLI debugger? Just drop breakpoint() in your code and you're in. Have been using it daily for over a decade and really happy with it - it's actually one of my favorite features of the language, amongst the many super useful features that Python and its excellent stdlib have to offer.

Honestly, I didn't know that and I'll try it. Last time I had to debug I remember adding "-m pdb" (as at the start of https://docs.python.org/3/library/pdb.html , first result in Google), but for some reason that immediately threw an error instead of starting the program, so I just chucked some prints in instead.

For complex problems, `import pdb; pdb.set_trace()` instead of a print statement can be super handy. It basically launches the debugger from the context of wherever you stuck the line.

For large unwieldy data-structures, you can go ipython: `import IPython; IPython.embed()` launches the ipython REPL from the calling line's context.

I use the latter a fair bit when spelunking around in other people's code. `pdb.set_trace()` lets you continue execution more easily.

Re: The unreasonable effectiveness of print debugging

#286

Post by galangalalgol »

zoomablemind wrote: post #283
dmitryminkovsky wrote: post #242

Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…

In a way, the print-debugging is a sign of 'owning' the code, when a developer is very much familiar with the structure and internal works of the project. This is akin to surgeon precisely pointing the scope and scalpel. Add to this a need to build a debugging-enabled version of the project - an often long-running process, compared to a few edits to some 'release' build. On the other hand, when dealing with an unfami…

I still resort to gdb, but mostly when I need memory access breakpoints for when someone (occasionally me) stomped on memory.

Re: The unreasonable effectiveness of print debugging

#287

Post by ruslan »

nyczomg wrote: post #278
zamfi wrote: post #166

Earlier quoted context omitted.

Print debugging always works, but also: it lets the programmer customize their view of the program’s (very, very large) hidden state in any way imaginable. Step debuggers are the “no-code” equivalent: extremely useful for the purposes for which they were designed—and often the better choice there—but inherently limited. Geoff’s not wrong in invoking Bret Victor’s Learnable Programming argument that being able to trac…

"Print debugging always works..." Nope, print debugging does not always work. Please stop saying that. Sure, it's often useful and often works. But go try to debug a race condition, or bug in some locking mechanism with print statements. I'll wait as you add a bunch of print statements, and then learn the harsh lesson that you are now debugging a completely different program with very different performance characteri…

You don't put printf() in critical sections, instead you collect some statistics. Once critical section is over you can freely print collected data for further analyzis. Or you can print it once a second. This simple technique works well for debugging racing conditions, performance issues (profiling), memory leaks, kernel drivers and bare-metal stuff where timing is a concern. So, yes "Print debugging always works...", but must be used wisely. :-)

Re: The unreasonable effectiveness of print debugging

#288

Post by boatsie »

1337shadow wrote: post #57
boatsie wrote: post #41

A few more reasons why print debugging is used. If you are debugging multiple things at once, you’ll have breakpoints set that aren’t necessarily needed at the moment, meaning you have to continue a bunch of times to get to the right spot. Or your breakpoint needs to be in a loop that is called multiple times and conditional breakpoints are a pain and subject to code errors in the condition itself. Many debuggers are…

> you’ll have breakpoints set that aren’t necessarily needed at the moment, meaning you have to continue a bunch of times to get to the right spot. Python: if something: breakpoint() Js: if (something) debugger; Much easier than breakpoint conditions in visual debuggers imho.

That runs the risk of forgetting to remove it.

Re: The unreasonable effectiveness of print debugging

#289

Post by socialdemocrat »

mumblemumble wrote: post #257
dmitryminkovsky wrote: post #242

Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…

There's a part of me that wants to say that that opinion has to be taken with a grain of salt and a lump of paying attention to who is offering it. Circa 1999, one would assume that Brian Kernighan and Rob Pike are largely drawing experience from working with C, which is a relatively verbose language. Single stepping through C code in a debugger is indeed a laborious process. If you read accounts from Smalltalk devel…

I guess you could view it that way although I prefer to think of what Smalltalk developers do as living inside a REPL. And that is indeed something I can relate to. I program Julia and I basically stay in a REPL all day. But I don't regard that as the same as using a debugger. Like a Smalltalk developer, I evaluate specific functions/methods with particular values. I don't step through code. I am pretty sure Smalltalk developers don't step through code a lot.

Rather they do live changes of their code, and then evaluate various objects to verify that things work as expected. That how I seem to remember working in Smalltalk many years ago.

I am not a fan of debuggers, although I do use the REPL a lot. I suppose like Rob Pike, I used them only for very limited tasks, such as getting a stack trace or getting some sense of control flow. But as soon as I have that, I spend more time looking at code and reasoning about it, than stepping in a debugger. With a REPL I can try out assumptions I make about the code, rather than being forced to step through it.

Post reply on HN