4 ms·

I don't know you or your work. But I know (senior) developers that don't use a debugger and I've often noticed that when fixing a bug, they don't build a full m

by planb 1y ago

I don't know you or your work. But I know (senior) developers that don't use a debugger and I've often noticed that when fixing a bug, they don't build a full mental model of what really goes wrong and often just fix the symptoms. Think "that shouldn't be null, we need a null check here" instead of "why is this value null? we should check here, but also make sure the caller works correctly."

johnisgood 1y ago
You can have that kind of thinking or mental model with and without debuggers though. I do not see how it is relevant to debuggers.
vacuity 1y ago
On the other hand, though this is n = 1 and from 2000 (and it is classic Linus): Linus Torvalds: > I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program. > I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. > Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger. > I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65 And I agree. At least for me, print debugging goes a long way, and I'm already invested in building mental models about code. I think using a proper debugger has to be the last resort, because nothing else works and it's time to get into the ugly details. Two valuable avenues for producing good code are formal verification (and its ilk, such as specification) and horse sense/common sense, which combine to say that we should have rigorous mental models that impose on our code. That's the primary objective, to me. The use of tools such as debuggers is secondary, and in my experience, largely neutral or harmful. There's the classic caveat of "if your goal is to ship code fast, then this isn't practical", which is fair, but I have some things to say about shucking off that culture.
- skydhash 1y ago
  Debugger for me is more about inspection than actual debugging, especially when dealing with a complex systems. It's possible to just use a printf, but the debugger gives more information. It's rare that I need to do stepping. I mostly just want to see the stack trace and the state of the program. One of the nice thing about Common Lisp and Smalltalk is to be able to do this any single point.
  - igouy 1y ago
    Do this at any point and then change the state of the program.

by planb 1y ago

johnisgood 1y ago

You can have that kind of thinking or mental model with and without debuggers though. I do not see how it is relevant to debuggers.

vacuity 1y ago

On the other hand, though this is n = 1 and from 2000 (and it is classic Linus): Linus Torvalds: > I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program. > I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. > Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger. > I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65 And I agree. At least for me, print debugging goes a long way, and I'm already invested in building mental models about code. I think using a proper debugger has to be the last resort, because nothing else works and it's time to get into the ugly details. Two valuable avenues for producing good code are formal verification (and its ilk, such as specification) and horse sense/common sense, which combine to say that we should have rigorous mental models that impose on our code. That's the primary objective, to me. The use of tools such as debuggers is secondary, and in my experience, largely neutral or harmful. There's the classic caveat of "if your goal is to ship code fast, then this isn't practical", which is fair, but I have some things to say about shucking off that culture.

skydhash 1y ago
Debugger for me is more about inspection than actual debugging, especially when dealing with a complex systems. It's possible to just use a printf, but the debugger gives more information. It's rare that I need to do stepping. I mostly just want to see the stack trace and the state of the program. One of the nice thing about Common Lisp and Smalltalk is to be able to do this any single point.
- igouy 1y ago
  Do this at any point and then change the state of the program.