Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t look down on print debugging

blog.startifact.com

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Don’t look down on print debugging

#141

Post by never_inline »

johnisgood wrote: post #114
stitched2gethr wrote: post #58

Earlier quoted context omitted.

I have a perfect solution for this, that works for me at least. Adding a `..` to the end of a variable triggers a macro that changes `val` into something like `print("val:", val) // FIXME: REMOVE`. Then a pre-commit hook makes sure I am unable to commit lines matching this pattern.

That could work, but there is a problem with this approach (the last part of it): Not all projects use git, but the ones that do: It is possible to set up a global pre-commit hook in git, but it requires some manual configuration because git does not natively support global hooks out of the box. By default, hooks are local to each repository and reside in the .git/hooks directory. You could do: git config --global co…

There's a python tool called `pre-commit` which may be helpful. Its used very much in python ecosystem.

Re: Don’t look down on print debugging

#142

Post by anal_reactor »

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 problem with deguggers is that they're scoped to one particular technology, and by the time I learn how to use it, I'm already in a new project, doing new things. Meanwhile print is almost universal.

Re: Don’t look down on print debugging

#143

Post by _0ffh »

llm_nerd wrote: post #101
_0ffh wrote: post #59

Earlier quoted context omitted.

Speaking from my own experience I'm not so sure that printf debuggers just have "incomplete knowledge [...] of modern debugging tools". I use printf (or the file-based equivalent, log files) quite a lot, but nobody can accuse me of not knowing good debugging environments. Also, what's "modern" about "Walk the call stack! See the parameters and values, add watches, set conditional breakpoints"? Those are all things we…

I said such users often have incomplete knowledge. Are there exceptions? Sure. Of course there are. "Those are all things we had many decades ago" I didn't claim this is some new invention, though. Though as someone who has been a heavy user of debuggers for DECADES , debuggers have dramatically improved in usability and scenarios where they are useful. "So please refrain from calling people with different preference…

Yeah, it's still the same point of "if only they know what I know". And no need to shout, so have I.

Re: Don’t look down on print debugging

#144

Post by ufmace »

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

> And if you step past something but then later realize it was important, time to start over. How can you do this using print debugging? For every print statement I add, I can add a breakpoint. Even more importantly, I can see the stack frame and know which functions led to the current one. I can inspect any and all variables in scope, and even change their values if I want to pretend that the code before was fine an…

What I mean here is, with print debugging, the setup is usually you have a run or test case that you start, spits out a bunch of text from the prints, and is complete in a second or two. With an interactive debugger, you often end up spending a while stepping around and through things and watching how data flows or changes. Then it can be a pain if you realize something was important after you stepped past it.

Granted, there's nothing really stopping you from using an interactive debugger with frequent short executions, but using print debugging seems to encourage it and interactive debuggers kind of discourage it.

Re: Don’t look down on print debugging

#145

Post by eggdaft »

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

Browser debugging tools are very basic. Their UI is generally awful.

Spend a few days debugging in PyCharm and you'll scream when you open developer tools.

Re: Don’t look down on print debugging

#146

Post by bbkane »

do_not_redeem wrote: post #63
bbkane wrote: post #17

Earlier quoted context omitted.

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();

Agreed, but I wonder what the OP is missing in their webdev debugging journey that exists elsewhere

Re: Don’t look down on print debugging

#148

Post by baq »

orwin wrote: post #128
baq wrote: post #109

Earlier quoted context omitted.

You’re absolutely right - but it’s worth mentioning that print debugging is the only sanity-preserving way to debug distributed systems (spans are basically super fancy prints) or systems which need to run at full speed (optimized builds) to reproduce bugs… sometimes the easy way is the only way.

Isn't it better to use a logger than print statements for distributed systems? Maybe I'm putting too much logging everywhere, but distributed systems are typically a use case where a bug can appear, be 'fixed' (or 'fix itselfn) , then re-appear two month later (the eisenbug). In this case, DEBUG=true and relaunching the app with a logger is often better imho (and if your logger is good, it prints on stdout/stderr whe…

Absolutely - if you want to make this distinction. I put logger.debug() and print() in the same bucket; if you're fancy, you've configured your print to emit logs or configured your linter to forbid print calls.

Re: Don’t look down on print debugging

#149

Post by armada651 »

Barrin92 wrote: post #69

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 ha…

Agreed, but print debugging should also not be entirely dismissed. It is not the first tool you should reach for, but it is a valuable tool when your more sophisticated tools fail or are not a good fit for the job.

It also ties into the importance of logging. If you know how to do print debugging well you'll know how to do logging well. And while a crash dump is very useful and allows you to inspect the crash with a debugger, only a good log can give you the necessary context to determine what led up to the crash.

Re: Don’t look down on print debugging

#150

Post by dgfitz »

kazinator wrote: post #120
dgfitz wrote: post #81

Earlier quoted context omitted.

> So please refrain from calling people with different preferences uneducated. OP said: > … people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. I am educated. I have a metric fuckton of incomplete knowledge in all areas of life. You’re poking at something that wasn’t said.

I've never been able to successfully debug anything with a conditional breakpoint or watch, in spite of knowing about these things and trying. (Well, other than my own conditional breakpoint features built into the code, doing things like programmatically trigger a breakpoint whenever an object with a specific address (that being settable in the debugger interactively) passes certain points in the garbage collector.)

I work on a codebase daily that has multiple threads per app, and two event loops.

We have successfully sorted out how to manage both loops, and set effective breakpoints to debug efficiently. We also log extensively.

I know it’s possible because I do it every day.

Post reply on HN