[greenyoda]

The article neglects one of my most important use cases for a debugger: figuring out how an undocumented piece of legacy code works. For example, if I perform a particular action in the UI, does function foo() get called? I find that setting breakpoints and tracing execution and variable changes in a debugger is an effective way of doing this kind of reverse engineering.

Also, when you're working with code that takes a long time to compile and link, using a debugger to check program state can be a lot quicker than recompiling the code with added print statements.

Different developers work with different types of code in different environments, so just because Linus Torvalds or Rob Pike does something one way doesn't mean that this is the most effective way for everyone else to do it.

[cafard]

Upvoted.

Many years ago, we were installing an ERM system, when we discovered that it would not run payroll--or rather, it would run payroll for every employee except for the two who were in a certain jurisdiction. The very expensive consultants who were overseeing the implementation did not have any useful ideas on how to resolve this. (Though they did have a useless and time-consuming one.) I figured out how to use the COBOL debugger (called an "animator"), and in a couple of hours located the problem. Perhaps if I knew how to write COBOL printfs, I could have done without the animator, but I was all but illiterate in COBOL.

I have since inherited the care of a WinForms system, and without the Visual Studio debugger I'd be lost there.

I

[nisa]

Exactly. I seldom use it for my own code, can't remember the last time I did it but stepping through some huge undocumented Java codebase with Aspects oriented programming in it like Spring AOP (where the actual code that runs in that random function invocation is in some .xml file defined but not directly in the code) saved me a lot of time.

Also debuggers display contents of variables very nicely while stepping through code - for me a good way to verify my assumptions after reading a certain piece of code, just set a breakpoint and see if it's actually works that way - I'm often surprised.

Maybe it's not really required for C / low-level code but if you are wrangling complex Java codebases it's a very nice tool to have in the toolbox.