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

141–150 of 366 posts

Re: The unreasonable effectiveness of print debugging

#141

Post by hawkice »

corty wrote: post #132
throwaway894345 wrote: post #77

Earlier quoted context omitted.

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.

Also, in almost all languages debuggers are an afterthought. Take e.g. the situation with Golang, Haskell or Python. Either there is no useful debugger or there is one, but it came late and still cannot debug everything the language does.

Print debugging not (really) working is haskell is... Non-idea, and a bad pairing for bad real debugging. But test cases are usually easier to figure out. Presumably there's a balance discovered by people in big projects but it never seemed as good as normal approaches to me.

Re: The unreasonable effectiveness of print debugging

#143

Post by kstrauser »

Jeff_Brown wrote: post #128
kstrauser wrote: post #92

Earlier quoted context omitted.

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

Cool! Where can I read about what's going on in that?

Go to https://docs.python.org/3/reference/lexical_analysis.html#f-... and search for “ New in version 3.8: The equal sign '='.”

Re: The unreasonable effectiveness of print debugging

#144

Post by adam_arthur »

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 stack to see what went wrong. I dare to say that in a single threaded context, it's almost objectively more effective.

Versus the alternative of using printlines, you basically need to map/model the state flow out in your head which is prone to error (limited capacity of human working memory).

Is it not easier to directly see the problem rather than doing mental math to make assumptions about the problem? I can't see a case for that being more effective.

Most of the time I see people print debugging it seems to be because they haven't used the debugger much... either they aren't comfortable with it, or didn't bother to set it up, or see the mental mapping approach as more "mathematical/logical"... or something. Takes you back to the school days of solving algorithms on paper :)

That being said for simple problems, I've used print debugging myself (again, usually because I'm too lazy to setup the full debugger). Or for multithreaded contexts etc, where thinking it through can actually be more effective than looking directly at the problem (multiple contexts)

Re: The unreasonable effectiveness of print debugging

#146

Post by SAI_Peregrinus »

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

You are missing out on the important point: printing forces you to formulate a hypothesis: what you expect and to compare with what you actually get. Debugging encourages less modeling and more trying random stuff until something sticks. It is an exaggeration. In practice, it is useful to apply both. Novices can get some insight using debugging, more experienced with code base people should exercise their understandi…

You can also do print debugging with a debugger. Just have a breakpoint that doesn't halt, but instead simply prints the values of interest to the debugger console. This is particularly nice for things like debugging interrupt handlers where the time taken to print output normally is too much to accept.

Re: The unreasonable effectiveness of print debugging

#147

Post by chromanoid »

ben509 wrote: post #32
chromanoid wrote: post #2

I usually only do print debugging when I encounter a Heisenbug. I mainly develop in Java, maybe my choice is related to its really really great debugging tooling.

The worst is when you put print statements in and a bug goes away, and you realize there's some kind of instruction reordering bullshit at work.

A simple toString() with side effects can be insidious when mixed with other bugs...

Re: The unreasonable effectiveness of print debugging

#148

Post by christophilus »

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…

Agreed. Also certain classes of bugs (such as bugs in parallelism) are easier to debug via print than using a debugger.

Re: The unreasonable effectiveness of print debugging

#149

Post by geocar »

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…

> For something that takes up the overwhelming bulk of a developer's time...

It isn't the bulk of my time.

Most of my time is spent figuring out what to do.

Once I have decided that, telling the computer is usually straightforward.

> Programmers don't often talk about debugging techniques in my experience.

No they don't, but look at it this way: Bugs are mistakes, and nobody wants to be told they're making too many mistakes. Anyone who discovers some amazing debugging technique will struggle to share it with anyone else for a lot of reasons, and this is one.

> It may be that nobody has a method superior to print debugging.

Print debugging always works. Getting "a debugger" to work isn't always easy, and if you aren't already comfortable using the debugger to track down the kind of bug you're facing, you will find it very difficult to find the bug and cure it faster than with print debugging. And since people don't tend to make the same mistakes over and over again, debuggers tend to have a very limited utility in those few mistakes made frequently.

My experience is that mistakes like that are the fault of some kind of fundamental misunderstanding, and rather than spend time to learn all of the different fundamental misunderstandings that the debugger was designed to work around, time is better spent simply correcting your misunderstandings.

Re: The unreasonable effectiveness of print debugging

#150

Post by username90 »

tester756 wrote: post #80
username90 wrote: post #75

Earlier quoted context omitted.

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

But it only stops at one thing at once. With print debugging I can print 100 things in different places and look at all of them at once giving me a temporal overview, I can't do that in a debugger.
Post reply on HN