4 ms·

Surprised nobody has posted this: https://lwn.net/2000/0914/a/lt-debugger.php3 https://lwn.net/2000/0914/a/lt-debugger.php3. The big problem with debuggers in g

Surprised nobody has posted this: https://lwn.net/2000/0914/a/lt-debugger.php3 https://lwn.net/2000/0914/a/lt-debugger.php3. The big problem with debuggers in general is that they encourage you to repair bad stuff rather than to create good stuff. When you reach for a debugger or a print statement, you're essentially saying to the machine, "I don't know how this code works, please tell me" and neither vehicle can really do that; all they can do is tell you what happened in a particular run. On the other hand, reading code can tell you how it works. However, frequently we have trouble reading and understanding which can often be resolved by seeing an output and properly generalizing a conclusion based on what you've read. But, you don't need to see a lot of output to answer a specific question. Odds are good that if you feel you need to see a lot of output then what you're doing is debugging a particular run rather than debugging the program itself. IMO, there is a big exception here when you want to understand the shape of data in a duck typed language. In that case, dumping an entire object can be useful just to see the shape of you data. This is something you could glean from reading but it generally doesn't change from one run to the next and is frequently left undocumented.

dorian-graph 5y ago
> The big problem with debuggers in general is that they encourage you to repair bad stuff rather than to create good stuff. Is that verifiable true?
- d0liver 5y ago
  Yes? I think we all agree that the point of a debugger is to repair stuff that's broken, right? Do you actively read and improve the surrounding body of code while you use the debugger? If so, what do you get out of the debugger?
imtringued 5y ago
That's not an argument against debuggers, it's an argument in favor of more machine verification e.g. through strict type checking. The expectation that we must understand every single line in a codebase to avoid minor mistakes like null pointers is a bit too much.
- d0liver 5y ago
  I'm definitely a fan of type checkers and formal verification. The problem is that even those tools permit not just specific bugs, but whole classes of bugs through verification; there are inherent limits on what any tool can give you. It's a similar thing with test cases, too. So, I'd say that when you use a debugger in tandem with a bunch of other good tools then the bad habits that the debugger encourages just matter less. There are fewer classes of bugs that will make it through verification and those other tools force you to understand the code at least well enough that you can pass their checks. However, you still need to read to generalize and fix those remaining bugs properly, and the debugger will push you toward a fast single point resolution rather than a slow but general resolution which is what you'd get from careful reading and thinking. The big argument against this is I think is if you're working with something where a large number of bugs is acceptable. Like, if you're hacking together a demo/prototype and you just need X to work then a debugger might be the way to go: Just ignore the other bugs because who cares? Or if you're working with some legacy software that's generally known to be buggy and you just need to fix some specific critical use case quickly. It's also just hard. Like you said, being able to read complex code and then systematically coax the bugs out of it with your brain and eyes definitely takes a lot of practice and the more that that can be supplemented by automation and good habits, the better.

dorian-graph 5y ago

> The big problem with debuggers in general is that they encourage you to repair bad stuff rather than to create good stuff. Is that verifiable true?

d0liver 5y ago
Yes? I think we all agree that the point of a debugger is to repair stuff that's broken, right? Do you actively read and improve the surrounding body of code while you use the debugger? If so, what do you get out of the debugger?

imtringued 5y ago

That's not an argument against debuggers, it's an argument in favor of more machine verification e.g. through strict type checking. The expectation that we must understand every single line in a codebase to avoid minor mistakes like null pointers is a bit too much.

d0liver 5y ago
I'm definitely a fan of type checkers and formal verification. The problem is that even those tools permit not just specific bugs, but whole classes of bugs through verification; there are inherent limits on what any tool can give you. It's a similar thing with test cases, too. So, I'd say that when you use a debugger in tandem with a bunch of other good tools then the bad habits that the debugger encourages just matter less. There are fewer classes of bugs that will make it through verification and those other tools force you to understand the code at least well enough that you can pass their checks. However, you still need to read to generalize and fix those remaining bugs properly, and the debugger will push you toward a fast single point resolution rather than a slow but general resolution which is what you'd get from careful reading and thinking. The big argument against this is I think is if you're working with something where a large number of bugs is acceptable. Like, if you're hacking together a demo/prototype and you just need X to work then a debugger might be the way to go: Just ignore the other bugs because who cares? Or if you're working with some legacy software that's generally known to be buggy and you just need to fix some specific critical use case quickly. It's also just hard. Like you said, being able to read complex code and then systematically coax the bugs out of it with your brain and eyes definitely takes a lot of practice and the more that that can be supplemented by automation and good habits, the better.