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

231–240 of 366 posts

Re: The unreasonable effectiveness of print debugging

#231

Post by steelframe »

wodny wrote: post #209

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed. For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from mul…

> I don't get printing being often ridiculed

I just told one of my co-workers last week that I was going to print-debug an issue. He paused for a moment before saying, "Uh, I can just debug this for you if you like."

So yeah, there's definitely some kind of stigma against print-debugging.

Re: The unreasonable effectiveness of print debugging

#232

Post by saagarjha »

corysama wrote: post #89

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 actually find GDB to be a fairly good debugger, but you need a bit of work in how to translate what your IDE is doing into something you can do in GDB.

Re: The unreasonable effectiveness of print debugging

#233

Post by saagarjha »

slaymaker1907 wrote: post #180

I agree about being able to see the whole program execution. This is particularly useful for multithreaded code since it provides a linear view into how the program actually executed. How are you supposed to figure out that A happened before B in a multithreaded program using only a debugger? With adequate logging, even if you don't log the precise times for A and B, you can often infer the ordering of these events b…

> How are you supposed to figure out that A happened before B in a multithreaded program using only a debugger?

Breakpoint at A, breakpoint at B, both automatically continue when hit.

Re: The unreasonable effectiveness of print debugging

#235

Post by humbleMouse »

wodny wrote: post #209

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed. For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from mul…

You’ve only used a debugger a couple of times in 10 years? Yikes.

Re: The unreasonable effectiveness of print debugging

#236

Post by saagarjha »

da39a3ee wrote: post #219

This should be a non-debate. A debugger is for when you want to inspect local state in detail. That can indeed often be very useful, and they are sophisticated technology. However, the people who think that a debugger is the only way to debug just aren't good programmers: often you want a picture of the overall behavior of your program. As has been said by someone other than me, a debugger allows you to fix a bug; pr…

Perhaps the people using a debugger have it set so it can give them a picture of the overall behavior of your program.

Re: The unreasonable effectiveness of print debugging

#237

Post by kaba0 »

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.

On the other hand, it is reall great in case of the JVM

Re: The unreasonable effectiveness of print debugging

#238

Post by blauditore »

wodny wrote: post #209

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed. For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from mul…

> I used a debugger only a couple of times and in most cases it was against someone else's code

The vast majority of code I investigate is "someone else's" code. Most of the cases, it's a historical accumulation by multiple authors. If you generally only work in your own code, that's quite a different experience, and debugging is generally easier (because you were there when it was written).

Re: The unreasonable effectiveness of print debugging

#240

Post by saagarjha »

wodny wrote: post #209

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed. For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from mul…

> My opinion is that if you can't reason about the code helping yourself with just a couple of additional messages the code is probably broken/too complicated to begin with and requires serious refactoring. I've never understood people stepping through a program hoping to find some mysterious creature somewhere along a huge stack of calls. In my career I have often seen people always debugging an application as a whole instead of separated modules. Dividing a problem is the key. The same key that allows me to still program using vim without autocompletion, keep APIs sane and coherent, and avoid dead code.

The big thing here is that you seem to only work with your own code, where you can arbitrary refactor it and keep the entire thing in your head, as well as quickly find which module does what. But when working with a large foreign project, none of this works. You have to start working at the scope of the entire program, because you have no idea of the internal structure yet. Of course, people who use debuggers divide the code up as they go, but the point here is that they place a few choice breakpoints at central points in the application logic, inspect the stacktraces when one gets hit, and use them to further dig in to the part of the code they need to look at.

Post reply on HN