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

111–120 of 366 posts

Re: The unreasonable effectiveness of print debugging

#111

Post by pmichaud »

I think the point about seeing the state over time is a great one.

But also I want to nitpick because the title is one of my “favorite” pet peeves: “The Unreasonable Effectiveness of ...” thing is now used (as in this article) by people who are trying to say that something is remarkably or surprisingly effective, but that’s not what the original essay was about at all!

“The unreasonable effectiveness of the mathematics in the natural sciences” was a philosophy of science piece whose thesis was that there is no reasonable (rational, provable) basis for the degree to which our math abstractions and syllogisms happen to correspond to the physical universe.

It is self evident that they do in fact correspond super well, but the original piece was about how weird and spooky that actually is, if you think about it at all. Math is super effective, and there is no reasonable basis that we yet know that it should be so effective. It’s unreasonably effective.

It’s such a perfect title for that piece, and it feels dirty or diluting when it’s just used to mean “remarkably effective.”

Re: The unreasonable effectiveness of print debugging

#112

Post by Blumfid »

Androider wrote: post #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…

Java debugger can easily drop frames which helps tremendously in going over a function multiple times.

Hot code replacement, which I have already and still use since 2005 works very well as well.

In php, debugger are half as good but code replacement works immediately.

I would rarely use print debugging and in Java never.

Re: The unreasonable effectiveness of print debugging

#114

Post by thenoblesunfish »

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…

It‘s a very interesting point. I suspect it‘s hard to study because it‘s a very high level capability of our brains. If you understand how we debug, you understand a lot about how reasoning itself works. I did read a book on debugging as a general practice once, but it wasn‘t helpful, as it was mostly anecdotes and generalities.

Re: The unreasonable effectiveness of print debugging

#115

Post by dragonwriter »

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.

> And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved.

The problem is that the two print statements will only catch the bug if they are the right two, based on a correct hypothesis of what the bug is. Which, with a debugger, won’t require stepping, but setting two breakpoints, doing a run-to-breakpoint, and inspecting values.

Stepping is required when you are exploring behavior because you don’t have an easily testable hypothesis about the source of the bug.

Re: The unreasonable effectiveness of print debugging

#116

Post by lamontcg »

mekoka wrote: post #16

IDE vs Text editor. OOP vs Functional. Logger vs debugger. The holy wars that shouldn't be. Why can't we all be friends and accept that Vim is better than emacs.

I've been a vim print debuggerer for like 30 years, and last year picked up writing C# in an IDE (Rider) and its been quite nice really.

Re: The unreasonable effectiveness of print debugging

#117

Post by strikhedonia_ »

marco_craveiro wrote: post #59

I disagree slightly with the emphasis on "print debugging". I think what is missing is a body of theory around logging as a methodology. When I write code, I like to be able to look at the log file and "see" what the code is doing, when on DEBUG or higher. I think logging is a difficult but very important skill, and one which we are losing over time. If anyone is aware of any good books on logging (even if very old),…

Absolutely.

When people say they use 'print statements,' are they talking about log points (a debugger construct), logging or something else?

I should hope that, in most cases, they're not literally modifying their source code to achieve this. While there are a handful of scenarios in which this is necessary, on the whole it strikes me as inefficient, time-consuming and error-prone. In most environments, there are better ways to make this data observable.

Re: The unreasonable effectiveness of print debugging

#118

Post by jameshart »

The idea that print debugging is about being able to understand the time dimension of your code resonates, definitely. It reminded me of how the redux dev tools browser plug-in is an interesting pointer to a better kind of debugging. And essentially all that is is a rich UI around printing out the entire redux state after each operation. But because the redux state advances in discrete steps it’s very easy to express exactly what happened, and explore precisely what state change happened in response to each action. I do find myself wondering whether there’s a much richer debugging capability along those lines that could be applied more generally.

Re: The unreasonable effectiveness of print debugging

#119

Post by kbd »

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.

Never felt that Python debugging was "fragile". BTW if you're not using pudb you're missing out.
Post reply on HN