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

What a good debugger can do

werat.dev

Post reply on HN
Print view View original

171–180 of 208 posts

Re: What a good debugger can do

#171

Post by outworlder »

turtledragonfly wrote: post #95

I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a "printf debugging" aficionado (or better: real logging). I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it's a buggy, fuzzy, moving target i…

> Compare the above with logging: It is simple and trustworthy.

Is it though? Add concurrency and it's no longer simple. Have an operation running millions of times a second? Good luck even logging that fast enough. If you start adding logic to print only sometimes, now you get a poor-man's debugger.

Re: What a good debugger can do

#172

Post by turtledragonfly »

outworlder wrote: post #171
turtledragonfly wrote: post #95

I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a "printf debugging" aficionado (or better: real logging). I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it's a buggy, fuzzy, moving target i…

> Compare the above with logging: It is simple and trustworthy. Is it though? Add concurrency and it's no longer simple. Have an operation running millions of times a second? Good luck even logging that fast enough. If you start adding logic to print only sometimes, now you get a poor-man's debugger.

Yes, see the other sequence of comments[1] where I clarify that a bit. I didn't mean it as an unalloyed "always maximally simple and trustworty in all cases" claim. Sorry for the ambiguous wording.

Yet for me, in those high-concurrency/high-frequency situations, I feel like a debugger is also a pain to use and trust? In truth, I've had best luck solving those sorts of issues by old-fashioned thinking through it / talking it over with someone / creating hypotheses and testing them sort of analysis. And even for that, logging (or profiling, event tracing, and similar "dump lots of data" approaches) tends to produce better "see the big picture" information than a debugger's laser-like focus. Might come down to one's personality somewhat, too (:

[1] https://news.ycombinator.com/item?id=35101564

Re: What a good debugger can do

#173

Post by aflag »

thewebcount wrote: post #154
aflag wrote: post #138

Earlier quoted context omitted.

They have a little. But his main point is that debuggers distract developers from seeing the problem as a whole rather than just understanding what's going on the vicinity of that problematic line. So, the debugger incentivises small, targeted fixes rather than bigger solutions for more systematic problems. That aspect of debuggers hasn't changed in 23 years, because that's the whole point of debuggers anyway. Some p…

> But his main point is that debuggers distract developers from seeing the problem as a whole rather than just understanding what's going on the vicinity of that problematic line. So, the debugger incentivises small, targeted fixes rather than bigger solutions for more systematic problems. What a bizarre take. Just today I had to use a debugger to figure out where there was a deadlock in our program and why. No amoun…

There’s more than one way to skin a cat. People not using a debugger are not mindlessly adding prints, sort of a poor man’s debugger. Those people are figuring out the problem from a different perspective. In your case, one may trying to come up with a theory as to what could cause a deadlock and think of ways to cause it to always happen consistently. Before running anything, they would be trying to understand what could possibly go wrong. Then they test the theory. You can perhaps see that, if someone is always doing that, they can get quite good at it. They would also develop quite a good intuition on what to expect from the code base over time. Whereas, someone who just goes straight to a debugger may not develop such an intimate relationship with the code base.

It depends on individual’s strengths and weakness as well. Neither way is going to be better for everyone. Each person has to find out what works for them.

Re: What a good debugger can do

#174

Post by carapace »

cgh wrote: post #6
carapace wrote: post #3

Seems as good a hook as any to hang this rant... > a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point…

In the real world, programmers are brought into projects with literally millions of lines of code that have been developed over years or decades by tens or hundreds of programmers. They are under intense time pressure to fix bugs that they likely didn’t create. This is normal and debuggers are invaluable. No offence, but what you’re describing is a lovely ideal that only exists if you work mostly alone or on small th…

I hear you: people have been "doing it wrong" voluminously and for a long time. Ergo, fancy debuggers come in handy.

> This is normal...

That's the part that I have a problem with. We have leavened our entire complex civilization with software, it's important to get it right.

Re: What a good debugger can do

#175

Post by carapace »

AndriyKunitsyn wrote: post #9
carapace wrote: post #3

Seems as good a hook as any to hang this rant... > a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point…

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreove…

FWIW it sounds to me like you're using what effectively amounts to fancy 3D printf, eh? In other words logging/printf help "visualize" non-geometrical entities.

Re: What a good debugger can do

#176

Post by worksonmine »

jcranmer wrote: post #25
Decabytes wrote: post #14

I've always been curious about Debuggers. How do they work? How do they connect to a program and step through it. Why can't more compiled languages integrate debuggers inside of them so that you can debug the program without using a separate tool? And why can't we create interfaces to debuggers so that other text editors can integrate with them, much like how we do we LSPs? *EDIT* Thanks for all the responses! I've n…

> How do they work? Painfully. If you're on Linux, you get to use a mixture of poorly-documented (e.g., ptrace) and undocumented (e.g., r_debug) features to figure out the state of the program. Combine this with the debugging symbols provided by the compiler (DWARF), which is actually a complicated state machine to try to encode sufficient details of the source language, and careful reading of the specification makes…

Have you tried using vims :Termdebug? By default it's GDB but you can use rr or others inside of it. Just like anything else in vim you can extend it to fit your workflow.

It has some rough edges sure but I'm using it successfully with C and Rust. If you have tried but still don't like it what's your use-case?

Re: What a good debugger can do

#177

Post by [deleted] »

turtledragonfly wrote: post #166
andirk wrote: post #161

Earlier quoted context omitted.

I learned C++ on CodeWarrior (and then vi) and its debugger made me require a debugger whenever I write code. I am currently using PHPStorm (or any JetBrains) and its XDebug debugger. For Javascript, I use Brave/Chrome debugger. ...And I should use logs more. I am always in shock when I see people work on large projects with no debugger. I do printf/console.log all the time but HOW DO PEOPLE NOT STEP-STEP-STEP??

> HOW DO PEOPLE NOT STEP-STEP-STEP I think I have felt some of what you are feeling. The debugger is ... seductive (: For one thing, it is an educational experience, as you step along you are learning what your program is actually doing, which is a good mental checkpoint, especially when I was a more junior developer. I think a debugger as an educational tool is a big point in its favor. And so you may develop a posi…

[deleted]

Re: What a good debugger can do

#178

Post by Stratoscope »

tester756 wrote: post #168
Stratoscope wrote: post #167

Where I work (IBM Watson Orders) they sometimes call me "the debugger guy". I love a good debugger and what it can do for me. I don't use it only for debugging; it's also a great tool to help anyone understand a complex codebase like ours. Not sure how or why the code reaches a particular function? Set a breakpoint and then look at the call stack. It's all right there. And if you want to write some experimental code…

I call it debugger-driven-development and it is indeed great when you have to get quickly into huge, complex codebases. It allows you to learn them very fast. VS has great debugger for C# which allows you to do a lot of stuff when running the program, so sometimes I even develop the soft while having debugger and breakpoints attached

This is funny, that is exactly the term I use too:

https://news.ycombinator.com/item?id=29387515

Beware: you may get criticized for it as I was in that thread... :-)

Re: What a good debugger can do

#179

Post by brailsafe »

I would be curious if there are that many frontend people that don't use a debugger. You mostly have to open devtools in the browser anyway, and it has an unquestionably sophisticated set of debugging capabilities

Re: What a good debugger can do

#180

Post by darkteflon »

turtledragonfly wrote: post #95

I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a "printf debugging" aficionado (or better: real logging). I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it's a buggy, fuzzy, moving target i…

Great comment. Since it sounds like your jam, do you have any suggestions for reading on logging best practices in this context?
Post reply on HN