Don’t look down on print debugging • Hacker News Board

Re: Don’t look down on print debugging

#11

Post by frou_dh » Sat, Nov 23, 2024, 1:39 PM UTC

Shame? My perception is that the situation is quite the opposite, in that tons of people online proudly proclaim at any opportunity that they only use print-debugging.

Which in some cases I see as related to a sort of macho attitude in programming where people are oddly proud of forgoing using good tooling (or anything from the 21st century really).

Re: Don’t look down on print debugging

#12

Post by bbkane » Sat, Nov 23, 2024, 1:39 PM UTC

I think in many scenarios, print debugging wins the cost/benefit analysis - new project where I don't want to learn how to set up a debugger, trying to debug something really custom or specially formatted, etc.

However, if I know I'm going to be working on a project for a long time, I usually try to pay the upfront cost of setting up a debugger for common scenarios (ideally I try to make it as easy as hitting a button). When I run into debugging scenarios later, the cost/benefit analysis looks a lot better - set a breakpoint, hit the "debug" button, and boom, I can see all values in scope and step through code.

Re: Don’t look down on print debugging

#13

Post by tantalor » Sat, Nov 23, 2024, 1:40 PM UTC

zaphar wrote: post #5

Terr_ wrote: post #2

To me there are three requirements for me to be comfortable with a team culture of print-debugging. 1. If a breakpoint debugger exists for the stack, it should still be convenient and configured, and the programmer should have some experience using it. It's a skill/capability that needs to be in reserve. 2. The project has automatic protections against leftover statements being inadvertently merged into a major branc…

Why would debugging be a team culture thing? It's very individual in practice.

Agreed. I don't care how a team member debugs something as long as they can solve the issue.

Re: Don’t look down on print debugging

#14

Post by endanke » Sat, Nov 23, 2024, 1:40 PM UTC

gregjor wrote: post #3

If you feel shame because of random opinions and articles on the internet, I’d address that before worrying about “print” vs. a real debugger. I pretty much only use print debugging. I know how to use a real debugger but adding print/console.log etc. keeps me from breaking context and flow.

Even printing can have some side effects on the code, by introducing some extra latency that might implicitly fix a race condition, if that’s the bug in question. Not saying that it’s wrong, just funny to think about that race conditions are hard to debug with any kind of tool, either with debugger or printing.

Re: Don’t look down on print debugging

#15

Post by cjs_ac » Sat, Nov 23, 2024, 1:41 PM UTC

The problem with all these 'print debugging is good' and 'print debugging articles are bad' is that none of them provide any context. Print debugging is just one tool in a box full of tools. Pick the right one for the right job. An article that walks through how to make that decision would be very useful. An article that just picks a side in a decades-old debate is just noise.

Re: Don’t look down on print debugging

#16

Post by molf » Sat, Nov 23, 2024, 1:42 PM UTC

montroser wrote: post #9

Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…

To be fair though: printing also will likely impact timing and can change concurrent behaviour as well.

Still agree that print debugging is more useful in such situations (and I prefer it in general).

Re: Don’t look down on print debugging

#17

Post by bbkane » Sat, Nov 23, 2024, 1:44 PM UTC

eggdaft wrote: post #7

gregjor wrote: post #3

If you feel shame because of random opinions and articles on the internet, I’d address that before worrying about “print” vs. a real debugger. I pretty much only use print debugging. I know how to use a real debugger but adding print/console.log etc. keeps me from breaking context and flow.

I only use print debugging when working on the web, and your mention of console.log makes me think maybe you're in the same boat. It's an absolutely damning indictment of the developer experience for the web that this is the case. Why aren't our IDEs and browsers beautifully integrated like every other development environment I use integrates the runtime and the IDE? Why hasn't some startup, somewhere, fixed this and…

Don't browsers have some of the best dev tools out there? For example, you can use the `debugger`[0] statement in your JS code to trigger the in-browser debugger when that statement is hit (its basically setting a breakpoint).

0: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Don’t look down on print debugging

#18

Post by FpUser » Sat, Nov 23, 2024, 1:44 PM UTC

Multithreading and locking are the areas where print/blinking LED on microcontroller based stuff and some other trickery are useful. Otherwise I prefer "normal" debuggers like with powerful IDE

Re: Don’t look down on print debugging

#19

Post by throw__away7391 » Sat, Nov 23, 2024, 1:46 PM UTC

montroser wrote: post #9

Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…

I have also seen the print statements added for debugging alter the timing with the same effect on more than one occasion, appearing to “fix” the issue.

Re: Don’t look down on print debugging

#20

Post by oftenwrong » Sat, Nov 23, 2024, 1:47 PM UTC

I still use a debugger for much of my print debugging needs by setting non-suspending breakpoints. This is useful because it allows me to change the printing dynamically, set breakpoints in library code, attach to running processes, and more.