4 ms·

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

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 5y ago
The name "debugger" does not reflect what it does. A debugger does never remove the bugs that you put in your programs.
- willcipriano 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        > 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 5y ago
        > 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.
        foxfluff 5y ago
        Somehow we went from obvious at first glance to .. trace a variable and you find the problem eventually? Now the question is, how do you tell from the trace that the total is wrong? If you can write a function to check it in the debugger, you probably can -- with roughly the same effort -- write an assert() or (asserts) in the program where that variable is modified, and that'll ensure you'll be immediately notified the next time it goes wrong even before anyone notices let alone has time to dig out a debugger. I'd say the value of creating asserts is up there with unit tests. You can object that actually the problem is in the complicated business logic and is already gone by when the assert fires and the wrong value is finally assigned/updated to the variable, but that same problem would come up in a debugger too. At one point your debugger notices that whoops it's gone wrong, but you don't know how exactly how you got there? Like I said in another thread here, things like rr can really change debugging (allowing you to rewind time, sort of) when they become available to your platform & language, but until then, I just don't find very compelling arguments why inspecting bad state in business logic would be so much faster in a debugger than with printfs. I find debuggers useful mainly for some niche things (ok, which NULL or freed pointer did I dereference and segfault on?). Now if you have to make an argument about performance, go ahead, but that's kind of orthogonal and it goes both ways. Some programs run too damn slow under a debugger, sometimes you have to make a separate build with debugging info and different build options (again possibly with a massive performance impact) and figure out how to use all that in conjunction with the target system that only has a few dozen megabytes of spare RAM.. if running a debugger requires none of that but builds are slow for you, go for it.
balsam 5y ago
https://m.youtube.com/watch?v=y7YhCLUz-To 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 5y ago
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 5y ago
  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 5y ago
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 5y ago
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.

enriquto 5y ago

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

willcipriano 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      > 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 5y ago
        > 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.
        foxfluff 5y ago
        Somehow we went from obvious at first glance to .. trace a variable and you find the problem eventually? Now the question is, how do you tell from the trace that the total is wrong? If you can write a function to check it in the debugger, you probably can -- with roughly the same effort -- write an assert() or (asserts) in the program where that variable is modified, and that'll ensure you'll be immediately notified the next time it goes wrong even before anyone notices let alone has time to dig out a debugger. I'd say the value of creating asserts is up there with unit tests. You can object that actually the problem is in the complicated business logic and is already gone by when the assert fires and the wrong value is finally assigned/updated to the variable, but that same problem would come up in a debugger too. At one point your debugger notices that whoops it's gone wrong, but you don't know how exactly how you got there? Like I said in another thread here, things like rr can really change debugging (allowing you to rewind time, sort of) when they become available to your platform & language, but until then, I just don't find very compelling arguments why inspecting bad state in business logic would be so much faster in a debugger than with printfs. I find debuggers useful mainly for some niche things (ok, which NULL or freed pointer did I dereference and segfault on?). Now if you have to make an argument about performance, go ahead, but that's kind of orthogonal and it goes both ways. Some programs run too damn slow under a debugger, sometimes you have to make a separate build with debugging info and different build options (again possibly with a massive performance impact) and figure out how to use all that in conjunction with the target system that only has a few dozen megabytes of spare RAM.. if running a debugger requires none of that but builds are slow for you, go for it.

balsam 5y ago

https://m.youtube.com/watch?v=y7YhCLUz-To 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 5y ago

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 5y ago
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 5y ago

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 5y ago

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.