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

71–80 of 366 posts

Re: The unreasonable effectiveness of print debugging

#71

Post by CJefferson »

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

Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…

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.

Re: The unreasonable effectiveness of print debugging

#72

Post by Someone1234 »

This is why products like OzCode for Visual Studio[0] are interesting. With their ability to put in a breakpoint and see multiple variable's values instantly and "time travel" (i.e. limit step back through logic), it kind of gives you the print debugging benefits in regular debugging.

I've not seen anyone else try anything like this. There's a YouTube demo here:

https://youtu.be/82jq5cvl67E?t=1561

[0] https://oz-code.com/ozcode-production-debugger

Re: The unreasonable effectiveness of print debugging

#73

Post by roenxi »

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 developer's time the silence is in many ways deafening. It may be that nobody has a method superior to print debugging.

Re: The unreasonable effectiveness of print debugging

#74

Post by Agingcoder »

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

Re: The unreasonable effectiveness of print debugging

#75

Post by username90 »

tester756 wrote: post #68

I'd say that except some heavily multithreaded cases, then print approach may be due to lack of mature tooling I can't understand why would anyone prefer to write some print, when you can have Visual Studio's * break point * conditional break point * ability to place another break points when you're already on the other * expression evaluation at fly!! * decent possibility to modify code at fly I still remember case…

Print statements lets you see many things at once. Breakpoint only breaks at one thing. They are good for different things.

Re: The unreasonable effectiveness of print debugging

#76

Post by majjgepolja »

angst_ridden wrote: post #35

The beauty of printf debugging for a novice C programmer is that the recompiling with printfs changes the memory layout so your buffer overflow no longer segfaults you. ALternatively, your printf can use the wrong formatter string, and cause unrelated crashes. Such joy! Makes me nostalgic for the good old days.

> ALternatively, your printf can use the wrong formatter string, and cause unrelated crashes. Such joy!

What compiler are you using? Aztec C? Prehistoric C?

Re: The unreasonable effectiveness of print debugging

#77

Post by throwaway894345 »

bakatubas wrote: post #44
CJefferson wrote: post #23

Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…

As a counter-point, I think there’s an argument that folks don’t spend enough time in the debugger. But there’s a lot of value there and in fact one could use a debugger environment to unit test as even native debuggers have scripting environments. Personally, I think folks should master the debugger _first_ and during all steps learning a programming language. But similar to test-driven-development it’s a different…

I can believe there is value in learning a debugger, but debuggers could stand to improve significantly. Debugger UX is almost universally awful and per the parent it’s often difficult to get one up and running. Moreover, if you do your “print debugging” with log statements of the appropriate level, they can be useful in production which is perhaps the biggest value.

Re: The unreasonable effectiveness of print debugging

#78

Post by mmazing »

axaxs wrote: post #37
le-mark wrote: post #31

Earlier quoted context omitted.

I’m sorry but this is just ignorance, learning to use the debugger for the platform at hand is a basic skill every developer should master. So many times have seen developers use the debugger to troubleshoot and fixed issues and been perceived as a “ninja” (despise that term but that was the effect) because they knew how to use the debugger. I mean yeah keep printing lines, and keep being out performed by your debugg…

OK. And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved. Debuggers aren't bad. But neither is printing. Knowing when to reach for them is probably a bit more key.

Tools in a toolbox.

The worst developers I've ever known always have their "this is the best way to do everything" hill they die on.

Re: The unreasonable effectiveness of print debugging

#79

Post by hnnameblah365 »

I think there's a conflation of processes and tools which leads to the false comparison. Print debugging is a process, which uses a tool called print statements. Stepping through code is a process, which uses a tool called the debugger.

Print debugging excels at triaging the problem. And every language has print statements. Ubiquitous first tier support. They help you narrow down where your assumptions about the program behavior may be wrong.

Once you know what area to focus on, you pull out the debugger and step thru the code.

Re: The unreasonable effectiveness of print debugging

#80

Post by tester756 »

username90 wrote: post #75
tester756 wrote: post #68

I'd say that except some heavily multithreaded cases, then print approach may be due to lack of mature tooling I can't understand why would anyone prefer to write some print, when you can have Visual Studio's * break point * conditional break point * ability to place another break points when you're already on the other * expression evaluation at fly!! * decent possibility to modify code at fly I still remember case…

Print statements lets you see many things at once. Breakpoint only breaks at one thing. They are good for different things.

> Breakpoint only breaks at one thing.

One breakpoint breaks at one thing, that's why you can have many of them

Post reply on HN