Live data from Hacker News

Why I use a debugger

blog.pnkfx.org

11–20 of 80 posts

Re: Why I use a debugger

#11
post #3

I thought using debuggers was standard practice in non trivial programs?

You'd think. But I still see discussions in JavaScript and PHP related threads where people swear by adding `console.log`/`var_dump` statements to their code over using the debugger. I've seen quite a few threads on r/php where individuals introduce a newer, supposedly better, library that can be used instead of `var_dump`, and there's always the inevitable "why not use the debugger?" to which many reply "because it'…

Logging has the benefit of not stopping your programs. On what I work on stopping the program is not feasible. It will block all of the clients trying to communicate with it and if you pause for too long the clients will disconnect and this may make the problem hard to reproduce. Additionally it can be difficult to attach a debugger on a remote machine compared to deploying a simple update which mechanisms already exist for doing.

Re: Why I use a debugger

#12

On one of Gordon Ramsey's shows he had a chef who purported to be one of the best in the world. While cooking his scallops kept sticking to the pan, this makes them look bad and Gordon won't serve them looking like that. Gordon yelled something like "Why aren't you using the non-stick pans, it's right there in the name, non-stick". I hear his voice in my head at least once a month when one of the people I work with s…

The name "debugger" does not reflect what it does. A debugger does never remove the bugs that you put in your programs.

Re: Why I use a debugger

#13
How quickly do you guys whip out the debugger when you encounter a bug?

I often can figure it out by reading the code (I'm the quickest jump-to-source in the wild west!) quicker than I can from inserting print stmts or hooking up a debugger.

I've also decided that I dislike having my IDE be my debugger, I prefer having an entirely separate UI for that. Maybe this is because I use Emacs and DAP mode and gdb is quite poor there, I'd rather use something like gdbgui.

Re: Why I use a debugger

#14

I thought using debuggers was standard practice in non trivial programs?

It really depends on a lot of things. Debuggers can completely throw off timing, concealing the bug you're after. Debuggers may tell you that your program state is messed up (doh, sure), but not how you got there. Figuring out how you got there isn't necessarily any easier with a debugger than with generous logging. If anything, it can be much harder. Figuring out where exactly to break or which particular instance of a million dynamically allocated objects to watch, etc. is no easier with the debugger than it is reading the source code.. Single stepping sucks when you don't know where your things go haywire. You spend too long in the wrong part or speed right through the problematic part. So you gotta restart and do it all over again, rinse and repeat if there's a pile of abstractions between where you are and where the problem is. ($deity/printf() help you if you're looking at a task composed of tiny asynchronous events and any attempt at stepping forward in the code just throws you back into the guts of the async executor, ready to pop off a completely unrelated event from the queue.)

If anything, I think debuggers are nice for simple, borderline trivial programs where everything fits on a screen and there's a handful of variables to keep track of. (These tend to be the programs I rarely need a debugger for though, and the debugger isn't necessarily any faster than a bunch of print statements). They're nice for getting stack traces or figuring out the contents of RAM and sometimes that's just what you need, but often that's just working your way backwards towards the real issue, without having a way to rewind time.

rr might change a lot of that, if it's available for your platform..

Re: Why I use a debugger

#15

On one of Gordon Ramsey's shows he had a chef who purported to be one of the best in the world. While cooking his scallops kept sticking to the pan, this makes them look bad and Gordon won't serve them looking like that. Gordon yelled something like "Why aren't you using the non-stick pans, it's right there in the name, non-stick". I hear his voice in my head at least once a month when one of the people I work with s…

The name "debugger" does not reflect what it does. A debugger does never remove the bugs that you put in your programs.

If your IDE is anything like mine, you will have a little button with a bug on it. You don't click it, even out of desperation at any point in your career? I get really tired and demotivated working with people who are like that, you have to hand feed them everything. Come to think about it, using the debugger is probably the best indicator I've seen if you are a good programmer or not, I've never seen anyone bad at programming use one.

Re: Why I use a debugger

#16

I thought using debuggers was standard practice in non trivial programs?

I have mentored a number of software developers from just starting their career to a decade+ long career. Nearly every time I open the debugger to help them work through an issue I get 'what is this? Why has no one ever told me about this?'.

This is not a judgement, just an observation. I always assumed debuggers were just part of a tool set but it appears (in my experience) many individuals were never taught that it exists.

I also do not claim its a magical tool that can solve all problems. There are plenty of times i do a "print 'i'm here' + var".

Re: Why I use a debugger

#17

How quickly do you guys whip out the debugger when you encounter a bug? I often can figure it out by reading the code (I'm the quickest jump-to-source in the wild west!) quicker than I can from inserting print stmts or hooking up a debugger. I've also decided that I dislike having my IDE be my debugger, I prefer having an entirely separate UI for that. Maybe this is because I use Emacs and DAP mode and gdb is quite p…

I only use the debugger when I'm really lost or when I'm suspecting compiler/inheritance/indirection shenanigans. Most of the time I try to add logging/tracing because those are reusable and can help me debug other issues later, and just the action of actively thinking where to put them and why often points me to the bug and the possible fix.

Re: Why I use a debugger

#18

Earlier quoted context omitted.

The name "debugger" does not reflect what it does. A debugger does never remove the bugs that you put in your programs.

If your IDE is anything like mine, you will have a little button with a bug on it. You don't click it, even out of desperation at any point in your career? I get really tired and demotivated working with people who are like that, you have to hand feed them everything. Come to think about it, using the debugger is probably the best indicator I've seen if you are a good programmer or not, I've never seen anyone bad at…

My point is that the debugger may help you understand the bug, but does not remove it. A better name for the tool would be something like bugfinder, or steprunner.

> You don't click it, even out of desperation at any point in your career?

I think I've never used an IDE since the (good) times of borland C++.

> I get really tired and demotivated working with people who are like that

You would probably hate working with me then... sorry about that.

Re: Why I use a debugger

#19

How quickly do you guys whip out the debugger when you encounter a bug? I often can figure it out by reading the code (I'm the quickest jump-to-source in the wild west!) quicker than I can from inserting print stmts or hooking up a debugger. I've also decided that I dislike having my IDE be my debugger, I prefer having an entirely separate UI for that. Maybe this is because I use Emacs and DAP mode and gdb is quite p…

I suspect this will be controversial, but I read TPOP at a young age and I think it still summarizes my overall view. The quote from the article continues:

Blind probing with a debugger is not likely to be productive. It is more helpful to use the debugger to discover the state of the program when it fails, then think about how the failure could have happened. Debuggers can be arcane and difficult programs, and especially for beginners may provide more confusion than help. If you ask the wrong question, they will probably give you an answer, but you may not know it's misleading.

In the ~15 years since I read this I've seen dozens of colleagues try to use a debugger in place of thinking harder, and it never goes well. Sometimes, but much more rarely, I see someone use a debugger after thinking hard for a while. That usually goes excellently, and probably creates some unrealistic view of the tool's effectiveness because other programmers see the debugger and not the thinking. 99% of problems are solved during the "think harder" stage, and if I can't think my way out of some local problem I probably wrote too-complicated code anyway. (And if it's a non-local problem, the debugger may not help too much.)

The goal of most IDEs seems to be first help with a debugger / executing code/tests, second help with writing code, and only thirdly help with reading code. The older I get, the more those priorities seem inverted to me.

Re: Why I use a debugger

#20

I thought using debuggers was standard practice in non trivial programs?

I hardly ever use them. I think it's mainly that I don't know how. I also generally dislike having to learn "context specific" tools, since you generally need different debuggers for different languages/environments/runtimes.

I also do a lot of low level code (kernel/bootloader) where debuggers can be available but are often a lot harder to setup. Keep in mind that I also don't like IDEs and my coding setup is mostly vim + ctags + terminal.

I really agree with the quote in TFA, when I write rust code a few judiciously placed dbg!() calls are generally all I need to identify the issue.

Post reply on HN