HN Distilled

Essential insights from Hacker News discussions

Things you can do with a debugger but not with print debugging

Original Article

Hacker News Discussion

The Hacker News discussion revolves around the utility and effectiveness of debuggers versus printf (or print) debugging, with a strong emphasis on the advanced capabilities of debuggers, particularly hardware watchpoints. Many users advocate for debuggers as essential tools, while others defend printf debugging or highlight the practical limitations and nuanced use cases of each approach.

Hardware Watchpoints as a Powerful Debugging Tool

A significant theme is the power of hardware watchpoints, which allow developers to break execution when a specific memory address is read or written. This capability is highlighted as a significant advantage over printf debugging for complex issues like memory corruption.

  • "Author missed one of the best features: easy access to hardware breakpoints. Breaking on a memory read or write, either a raw address or via a symbol, is one of the most time saving debugging tools I know." - swaits
  • "Very roughly, hardware watchpoints are memory addresses you ask the processor to issue an 'event' for when they're read from, written to, or executed. This event is processed by the kernel, and passed through to the debugger, which breaks execution of the program on the instruction that issued the read/write/exec. A concrete use case for this is catching memory corruption. If your program corrupts a known piece of memory, just set a hardware watchpoint on that memory address and BOOM, the debugger breaks execution on exactly the line that's responsible for the corruption. It's a fucking godsend sometimes." - jesse__
  • "State changes that can't be easily isolated. Sometimes you want to log when something change but can't for the life of you figure out when it's changing. Debuggers have watchpoints." - ajross

Debugger Scripting and Extensibility

The discussion also touches upon the extensibility of debuggers through scripting, which can automate complex validation and knowledge sharing within teams.

  • "windbg used to offer scripting capabilities that teams could use to trigger validation of any number of internal data structures essentially at every breakpoint or watchpoint trigger. it was a tremendous way to detect subtle state corruption. and sharing scripts across teams was also a way to share knowledge of a complex binary that was often not encoded in asserts or other aspects of the codebase." - coderatlarge
  • "This still exists? You can also use JavaScript to script/extend and there is a native code API too." - bpye

Debuggers vs. Print Debugging: A Contentious Debate

A central conflict in the discussion is the perceived superiority of debuggers over printf debugging. Many argue that printf debugging is insufficient for complex problems and that debuggers offer a more efficient and insightful approach.

  • "Oh my god, same. This literally catches bugs with a smoking gun in their hand in a way that's completely impossible with printf. I'd upvote this 100 times if I could." - jesse__
  • "No way, sorry. The bug you're trying to squash isn't complicated enough if print statements are as valuable as a debugger. And I get what you're after - this is coming from someone who regularly uses grep to answer questions faster than my clients' dopey ETL/DB setups." - thr0w
  • "I am surprised all the time in this industry how many software engineers still debug with printf. It's entirely baffling how senior / staff folks in FAANG can get there without this essential skill." - gigel82
  • "It's entirely baffling how senior / staff folks in FAANG can get there without this essential skill." - gigel82
  • "Is this not taught anymore? I started on borland C (the blue one, dos interface) and debugging was in the curriculum, 25+ years ago. Then moving to visual studio felt natural with the same concepts, even the same shortcuts mostly." - NitpickLawyer
  • "Honestly, I feel like the print vs. debugger debate isn't about the tool, it's about the mindset. Print statements feel like you're just trying to patch a leak, while the debugger is about understanding the plumbing. I’m starting to think relying only on print is a symptom of not truly wanting to understand the system you're working in." - untrimmed

The Practicality and Accessibility of Debugging Tools

Several users emphasize the importance of accessibility and ease of use when it comes to debuggers, particularly in modern IDEs like VSCode. The perceived difficulty of setting up and using debuggers is often cited as a reason some developers avoid them.

  • "With VSCode it's often a 10 minute job to set up. We are spoiled! Back in the VS days using a Microsoft stack it was just there. Click to add breakpoint then F5." - giveita
  • "I had a think about where I first learned to use a debugger. The combo of M$ making it easy for .NET and VB6 and working professionally and learning from others was key. Surprised it is less popular. Tests have made it less necessary perhaps BUT debugging a unit test is a killer move. You quickly get to the breakpoint and can tweak the scenario." - giveita
  • "But where you have a much more powerful tool specifically built for this purpose, wouldn't you, as an engineer, attempt to optimize your troubleshooting process?" - h4ch1
  • "All of these are useful skills in your toolkit that give you a way of reasoning about programs. Sure you can plop console.logs everywhere to figure out control/program flow but when you have a much more powerful tool specifically built for this purpose, wouldn't you, as an engineer, attempt to optimize your troubleshooting process?" - h4ch1
  • "Even never needed a debugger for complex kernel drivers — just prints." - BobbyTables2

Limitations and Alternative Tools

Commenters also acknowledge that debuggers are not a universal solution and that other tools like printf, REPLs, and logging frameworks have their own strengths and use cases. Some argue that printf can be more suitable for specific scenarios, especially those involving timing-sensitive bugs or when debuggers are not readily available.

  • "The debugger will never be completely transparent, it also eats resources in parallel to your application, and peeking into the session also introduces timing issues, short of the debugger itself having its own bugs. I'm saying it would be dumb to dismiss all other tools for the love of debuggers, it's just one tool in the toolbox." - makeitdouble
  • "While a debugger is of high value, having access to a REPL also covers the major use cases. In particular, REPL tools will work on remote session, on pre-production servers etc. if the code base is organized in a somewhat modular way, it can be more pleasant than a debugger at times." - makeitdouble
  • "With native languages you'll almost always be using a compiler that can output debug symbols, and you can use the output of any compiler with (mostly) any debugger you want. For JS in the browser, there's a often chain of transformations - TypeScript, Babel, template compilation, a bundler, a minifier - and each of these makes the browser debugger work worse -- and it's not that great to begin with, even on plain JS. Add that to the fact that console.log actually prints objects in a structured form that you can click through and can call functions on them from the console, and you start to see why console.log() is the default choice." - nananana9
  • "The rare ones show up maybe 1% of the time—they demand a debugger, careful tracing, and detective work. The 'oh shucks' kind where I am half sure what it is when I see the shape of the exception message from across the room - that is all the rest of the time. A simple print statement usually does the trick for this kind." - bluishgreen
  • "For really hairy bugs in programs that can't be stopped (kernel/drivers/realtime, etc) logging works. And when it doesn't, like when you can't do I/O or switching of any kind, log non-blocking to a buffer that is dumped elsewhere." - m463
  • "If you have a race condition, the debugger is likely to change the timing and alter the race, possibly hiding it altogether. Race conditions is where print is often more useful than the debugger." - branko_d

The Importance of Tool Awareness and Education

A recurring sentiment is that many developers, both new and experienced, are simply unaware of the existence or capabilities of debuggers. There's a call to spread awareness and educate developers on these essential tools.

  • "It may sound obvious to folks who already use a debugger, but in my experience a decent chunk of people don't use them because they just don't know about them. Spread the good word!" - old_bayes
  • "yeah, tons dont know they exist. But there's also a lot of people - new and veteran - who are just allergic to them, for various reasons. Setting up a debugger is the very first thing i do when i start working with a new language, and always use it to explore the code on new projects." - nchmy
  • "I can tell you for a fact a lot of budding web developers don't even know a Javascript debugger exists, let alone something as complex/powerful as Valgrind." - h4ch1
  • "Don't show the discussion to John Carmack. He's baffled why people are so allergic to debuggers: https://youtu.be/tzr7hRXcwkw?si=beXGdoePRkbgfTtL" - troupo

Debugging in Different Environments and Languages

The effectiveness and usability of debuggers vary significantly across different programming languages, operating systems, and development environments. Users note that the integrated experience in Windows with Visual Studio is often superior to debugging in Linux environments.

  • "Depend on the language or setup debuggers can be really crappy. I think people here would just flee away and go find a better fitting stack, but for more pragmatic workers they'll just learn to debug with the other tools (REPL, structured logging, APMs etc.)" - makeitdouble
  • "It seems like windows, ide and languages are all pretty nicely integrated together?" - tayo42
  • "In fact its possible to jump to the graphical debugger from the Python REPL when running locally. PyCharm has this feature natively. In VSCode you can use a simple workaround like this: https://mahesh-hegde.github.io/posts/vscode-ipython-debugging/" - never_inline
  • "I am the author of the posted flamebait. I agree. I use IPython / JShell REPLs often when the code is not finished and I have to call a random function without entrypoint." - never_inline
  • "I can tell you for a fact a lot of budding web developers don't even know a Javascript debugger exists, let alone something as complex/powerful as Valgrind." - h4ch1
  • "IME console-based debuggers work great for single-threaded code without a lot of console output. They don't work that well otherwise. GUI-based debuggers can probably fix both of those issues. I just haven't really tried them as much. pdb is great for python, though." - squirrellous
  • "I once wrote a program that opened up all of my code, and at every single code curly brace, it added a macro call, and a guid." - VikingCoder
  • "I'm pretty sure in that interview at some point he realized becasue the debugger experience for developers using Linux sucks compared to Windows where he does most of his work. Alot of programmers work in a Linux environment." - tayo42
  • "I'm pretty sure in that interview at some point he realized becasue the debugger experience for developers using Linux sucks compared to Windows where he does most of his work. Alot of programmers work in a Linux environment." - tayo42

Debuggers for Exploring and Understanding Code

Beyond just debugging, some users highlight the value of debuggers for code exploration and understanding, using breakpoints to visualize code flow and quickly navigate through the codebase.

  • "They're not just for debugging." - willtemperley
  • "Some debuggers allow you to see entire GPU workloads, view textures etc. Debuggers are extremely useful for exploring and helping edit code. I can't be the only person that sprinkles breakpoints during development which helps me visualise code flow and quickly jump between source locations." - willtemperley

Historical Debugging and Observability

The concept of historical or offline debugging, where execution is logged and can be replayed or analyzed later, is also introduced as a powerful technique, bridging the gap between logging and traditional debugging.

  • "Something I haven't seen discussed here that is another type of debugging that can be very useful is historical / offline debugging. Kind of a hybrid of logging and standard debugging. 'everything' is logged and you can go spelunk. For example: https://rr-project.org/" - jasonjmcghee