Live data from Hacker News

The unreasonable effectiveness of print debugging

buttondown.email

91–100 of 366 posts

Re: The unreasonable effectiveness of print debugging

#91
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 other than asking people to go solve a bunch of real world problems in real world systems for a few years?

Re: The unreasonable effectiveness of print debugging

#92

For print debugging in Python I recently discovered a nice little time-saver: the icecream package. Rather than having to type "print( "x: ", x )", you can instead type type "ic(x)". [1] https://github.com/gruns/icecream

Also, “print(f’{x=}’)” without an external dependency.

Re: The unreasonable effectiveness of print debugging

#93

(I have already replied to another comment with the same suggestion). Pernosco offers the best of both worlds ( debugger, print), along with a few magical features. https://www.pernos.co With it you can print anything present in your recording and step, and do anything you'd do in a regular debugging.

It's good to see that they hope to provide « the best printf debugging experience you've ever had », but I'm disappointed at the UI they show on the "Condition and print expressions" page.

The video shows the user using their mouse and typing the expression to be printed into a tiny text input.

Part of the attraction of print-style debugging is the convenience of being able to use your main editor UI, along with all the conveniences that provides, to write that expression.

(That might be fancy completion or vi-style editing commands or keyboard macros; it will be different for different programmers.)

Re: The unreasonable effectiveness of print debugging

#94
Speed of iteration beats quality of iteration.

You can step through the program, reason about what's going on, tracking values as they change. But if you missed the moment, you have start again from the beginning (time traveling debuggers being rare). Or maybe you're looking at the wrong part entirely at this stage, and just wasting time.

With print debugging you write a bit of code to test a hypothesis. Then you run it, and you keep running it, and especially if it's an UI program you play with the UI and see how the values change during that run. Ideally the loop to change the code -> see the result should be a few seconds.

You can then git commit or stash your prints, switch branches and compare behavior with the same changes applied. And at the end of the day if you walk away, your prints will still be there the next morning. The debugger doesn't produce any comparable tangible artifacts.

Once you do know where the problem is, and if it's not apparent what the problem is (most problems are pretty trivial once located), that's IMO the time to break out the debugger and slowly step through it. But the vast majority of problems are faster to solve through rapid iterative exploration with prints in my experience (C, C++ for over a decade, Python, now JS/TS).

Re: The unreasonable effectiveness of print debugging

#95
The limitation of print incentivizes me to write smaller functions and code that are generally free of mutations, so traces doesn't get stale fast.

Debugging on the otherhand, well.. I've just been told by my senior to write bigger functions, because the line-by-line debugging tool jumps around too much when moving between functions to functions.

Re: The unreasonable effectiveness of print debugging

#96
post #93

(I have already replied to another comment with the same suggestion). Pernosco offers the best of both worlds ( debugger, print), along with a few magical features. https://www.pernos.co With it you can print anything present in your recording and step, and do anything you'd do in a regular debugging.

It's good to see that they hope to provide « the best printf debugging experience you've ever had », but I'm disappointed at the UI they show on the "Condition and print expressions" page. The video shows the user using their mouse and typing the expression to be printed into a tiny text input. Part of the attraction of print-style debugging is the convenience of being able to use your main editor UI, along with all…

I suggest you tell them! They'll probably be happy to get some feedback.

If I'm honest, in spite of it not being perfect, it's much better than regular printf. The other very nice feature is dataflow (click on a variable value, and it tells you where it comes from, and it handles copies seamlessly), which makes a large number of debugging tasks trivial.

Re: The unreasonable effectiveness of print debugging

#97

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.

I just tried python -m pdb and it works for me https://dpaste.org/9EQo#L26 but I really always use breakpoint(). You can even configure it to use other debuggers with an environment variable, ie.: PYTHONBREAKPOINT=ipdb.set_trace

Re: The unreasonable effectiveness of print debugging

#98

In my experience, people who downplay debuggers don’t have the option to use effective debuggers. Debugging C++ and especially C# in Visual Studio is wonderful. Debugging Java in Eclipse can be great. Meanwhile GDB and most other language debuggers are painful and every IDE integration I’ve seen of them has been horribly unreliable. I’ve heard there’s a culture in parts of Google where kids go through uni using GDB b…

I dunno. I was a C# dev for 7 years and exclusively used Visual Studio's debugger. Then went to a JRuby project which had abysmal debugger support at the time. Learned to used printf style and it's now been my goto for the last 8 years. This despite coding in Nodejs for last 4 which has pretty good support. I only reach for the step through debugger when the problem is tricky, mainly because of having to do the setup.

Re: The unreasonable effectiveness of print debugging

#99
post #91
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…

> 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

I think this is exactly right. Teaching 1 is impossible I guess but the general method (it's basically the scientific method in an ideal environment) seems teachable.

Come up with a hypothesis of what's wrong, try to prove or disprove the hypothesis.

Post reply on HN