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

Re: Don’t look down on print debugging

#61

Post by mark_undoio » Sat, Nov 23, 2024, 2:30 PM UTC

llm_nerd wrote: post #22

While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…

Another thing I think leads people to print debugging - which is both a strength and a weakness of the approach:

It minimises the mental effort to get to the next potential clue. And programmers are naturally drawn to that because:

1. True focus is a limited resource, so it's usually a good strategy to do the mentally laziest thing at each stage if you're facing a hard problem.

2. It always feels like the next time might be it - the final clue.

But these can lead to a trap when you don't quickly converge on an answer and end up in a cycle of waiting for compilation repeatedly whilst not making progress.

Re: Don’t look down on print debugging

#62

Post by scotty79 » Sat, Nov 23, 2024, 2:31 PM UTC

I think that persistence of print debugging shows weaknesses of debuggers.

Complicated setup, slow startup, separate custom UI for adding watches and breakpoints.

Make a debugger integrated with the language and people will use it.

You can then pile up on it subsequent useful features but you have to get basic UI right first. Because half of programmers now are willing to give up stepping, tree inspection even breakpoints just to avoid dealing with the crappy UI of debuggers.

Re: Don’t look down on print debugging

#63

Post by do_not_redeem » Sat, Nov 23, 2024, 2:32 PM UTC

bbkane wrote: post #17

eggdaft wrote: post #7

Earlier quoted context omitted.

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

That's table stakes for a programming language these days I think.

JS: debugger;

C#: System.Diagnostics.Debugger.Break();

Rust: std::intrinsics::breakpoint();

Go: runtime.Breakpoint();

Zig: @breakpoint();

Re: Don’t look down on print debugging

#64

Post by thecrumb » Sat, Nov 23, 2024, 2:33 PM UTC

As a ColdFusion developer (it still pays the bills) I've been doing this forever as Adobe has never really built a good step debugger. Their latest IDE has one but it's very difficult to setup and is buggy when it does work. BoxLang is modernizing CFML (among other things) and has a nice, working step debugger... https://boxlang.io/

It's always so weird to switch to another language which DOES have a debugger...

Re: Don’t look down on print debugging

#65

Post by mark_undoio » Sat, Nov 23, 2024, 2:33 PM UTC

david-gpu wrote: post #31

If a good debugger is available, it is a great tool to have. But it is just one out of many tools. Some are more effective than others in different situations. For example, I rarely used a debugger in my career as an Android driver developer (mostly C), for several reasons. 1. My first step when debugging is looking at the code to build working hypotheses of what sort of issues could be causing the incorrect behavior…

FWIW if you're stuck on command line GDB it can be worth learning about TUI mode - "layout tui" which gives you side by side code and debug console.

It makes command history not work by default but IIRC "focus cmd" fixes that.

Re: Don’t look down on print debugging

#66

Post by Cannabat » Sat, Nov 23, 2024, 2:34 PM UTC

The article mentions it, but you can sum up print debugging as selectively enabling verbose/trace logging. “We’re about to do X” or “We just did Y, here is Z”.

A debugger gives you insight into the context of a particular code entity - expression, function, whatever.

Seems silly to be dogmatic about this. Both techniques are useful!

Re: Don’t look down on print debugging

#67

Post by PittleyDunkin » Sat, Nov 23, 2024, 2:34 PM UTC

llm_nerd wrote: post #22

While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…

> the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools.

While perhaps this is true of some sort of junior developer, I have both written my own debuggers and still lean heaviest on print debugging. It's trivially reproducible, incurs basically zero mental overhead, and can be reviewed by another person. Any day I break out a debugger is a bleak day indeed.

Profilers are much easier to argue for as it is very difficult for one to produce equivalent results without also producing something that looks an awful lot like a profiler. But in most cases the mechanisms you mention are just straight unnecessary and are mostly a distraction from a successful debugging session.

Edit: in addition to agreeing with a sibling comment that suggests different problems naturally lend themselves more to debugging (eg when writing low-level code a debugger is difficult to replace), I'd also like to suggest a third option languages can take: excellent runtime debugging ala lisp conditions. If you don't have to unwind a stack to catch an exception, if in fact you can modify the runtime context at runtime and resume execution, you quickly realize the best of both worlds without having to maintain an often extremely complex tool that replicates an astonishing amount of the language itself, often imperfectly.

Re: Don’t look down on print debugging

#68

Post by yunusefendi52 » Sat, Nov 23, 2024, 2:34 PM UTC

To be fair at least, I think in c# one should avoid Console.WriteLine as much as possible, because Console.WriteLine is blocking which make API request slow and instead use logger like serilog and use async sinks

Re: Don’t look down on print debugging

#69

Post by Barrin92 » Sat, Nov 23, 2024, 2:34 PM UTC

Print debugging is a disaster. If there's one widespread practice among non-beginner developers that wastes hours of time it's print debugging. I honestly can't tell how often I have seen people, even experienced programmers (usually because they insist on running some bespoke vim setup) refuse to use a graphical debugger to actually step through a program, and instead they spend hours hunting down bugs they could have found in ten minutes.

There's a section of an interview with John Carmack (https://youtu.be/tzr7hRXcwkw) where he laments the same thing. It's what the Windows/game development corner of the programming world actually got right, people generally use effective tools for software development.

Re: Don’t look down on print debugging

#70

Post by ufmace » Sat, Nov 23, 2024, 2:36 PM UTC

pzo wrote: post #35

ufmace wrote: post #30

I've used both print and proper debuggers plenty. I tend to lean on print debugging more these days. The thing about debuggers, in addition to often being a headache to set up, it usually seems tricky and time-consuming to get it to step to the lines you actually want to examine and skip the stuff you don't. And if you step past something but then later realize it was important, time to start over. It's often faster…

Agree, there are some time travel debuggers though but either only for some programming languages or expensive commercial or only for linux e.g. rr-debugger[0]. Also there is rerun [1] that is only for image processing pipeline debugging. I wish there was something similar like rerun but for code: you record the whole program running and capture all snapshots then stop it running. Now you can analyze all app executio…

Yeah it's a big enough pain point that I'm sure it's been done in at least some places. I'm not really sure it'd be worth the bother and memory consumption etc to set up though. Not when print is dead simple and works everywhere.

More like regular debuggers, it seems to me like it's something to set up only when print debugging just isn't getting the job done and you think you need something extra to help solve the problem.