[willcipriano]

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 spends a week on a bug and never once whips out a debugger. It's right there in the name guys.

[enriquto]

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

[willcipriano]

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.

[enriquto]

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.

[willcipriano]

Whatever works for you man, but if you spend two plus weeks on a bug in a if statement that would've been obvious at a first glance with a debugger, I'm not going to feel like we are contributing at the same level. It's like we are tasked with digging a ditch together and you want to use a tea spoon instead of a shovel.

[foxfluff]

> a bug in a if statement that would've been obvious at a first glance with a debugger

If you already knew which if statement to look at, it's irrelevant whether you use a debugger or printf().

Actually, it becomes even less relevant when you have thousands of dynamically allocated objects running the same statement but only one of them goes wonky and you only know which one it is later at runtime. In the end you end up doing the same logging and tracing with the debugger that you can do with a printf().

[willcipriano]

> If you already knew which if statement to look at, it's irrelevant whether you use a debugger or printf().

That's exactly when it matters, when you don't know where the problem is. You have a big ball of spaghetti business logic and a customer object that is passing through it. At some point the customers total balance is screwed up. You can:

- Read a lot of code and guess where that happens and set a printf or two, if you find it great, if not read more and set more printf's

- Set a watcher on the customers total, and review the logic each place it is modified and ensure it is correct before moving on

The first way you have to build the project over and over again, and you might miss something. The second way guarantees you find the problem eventually, and you only end up building a few times. If we have a project with a 5 minute build time, and a really thorny problem this can be a massive difference.

That isn't to mention the value of doing this in concert with the creation of a unit test that recreates the bug to further reduce the bugfix feedback loop.

[whizzter]

That's exactly when a GOOD debugger becomes useful, if you can get an hint at what's wrong you can often (if needed and the fault wasn't caught by the debugger) put in a good conditional expression for the breakpoint and only break once it fails, yet if every input looks fine and your code isn't a mutating mess you can set a previous line as the next statement and re-step what happened to create the error condition for the particular object.

Adding traces (probably over several iterations to narrow down things), rebuilding, rerunning and inspecting those traces would've probably taken multiples of the time to build and run everything up to the point of failure.

[cxr]

I can appreciate the teaspoon/shovel metaphor, which I've gotten a lot of mileage from myself—not necessarily always related to programming—but "a bug in a if statement that would've been obvious at a first glance with a debugger" does not reflect how debuggers actually work.

Signed,

Someone who actually likes debuggers but doesn't see you making a solid case for them at all.

[_n_b_]

I suspect GP was referring to a situation where you’re stepping though some problem code and see that you end up in the wrong clause or an IF statement?

Agree that’s not the first use case I’d think of, but I do think debuggers can quickly pinpoint that kind of thing as you step through code… if you know roughly where the problem is.

[balsam]

https://m.youtube.com/watch?v=y7YhCLUz-To

The truth is a bit less dramatic than you made it. Wasnt the best scallops chef in the world, at most the best of 5 trainees at a certain restaurant.

Makes me optimistic. Maybe there still is a world class programmer who doesnt use a debugger!

What makes me pessimistic is the lack of any usable rr equivalent for python. Think rpython had it or something but not the latest version.

[omnicognate]

You have colleagues who spend a week investigating a bug and it doesn't occur to them reproduce it under a debugger (as opposed to it not being debuggable for some reason, eg. not reproducible locally)? Really? And this happens at least monthly?

It's a curious observation. If it's true your work environment must be very different to mine.

[willcipriano]

Government. I gave it a year but I'm moving on soon (email in profile). Unit tests are a recent innovation they are proud of, I don't have to heart to tell them that they are all actually integration tests and don't really have the sort of assertions that would catch much of anything.

[agumonkey]

Debuggers are just a few hairs out of absolute relevance.

You just need a:

- ability to describe different points in the evaluation graph as one investigation set

- ability to bookmark restore these investigation set

- ability to visualize them in batch

bonus point:

- extract a patch from debugger interaction so you don't type again what you 'xplained to the debugger

[mellavora]

So you are right that a debugger is very useful for finding bugs.

But not all cooking pans are the same. The non-stick pan might not stick, but does it heat as evenly? Does it control the heat with the same stability? i.e. Gordon might have been being a dick.