Debuggers are for Losers(java.dzone.com)
java.dzone.com
Debuggers are for Losers
http://java.dzone.com/articles/debuggers-are-losers
4 comments
Quick quiz:
You've got a unit test that just failed. It's not immediately obvious what's going on, but it's possible some assumption about possible states your program can be in at this point turns out to be incorrect. In order to diagnose it in more detail, would you rather. . .
a) Start guessing at possible causes, and cycle through iterations of writing print statements to check for them and then running the program to see their output until you make a correct guess.
b) Start guessing at possible causes, and cycle through iterations of writing Assert() statements to check for them and running the program to see if anything throws until you make a correct guess.
c) Set a breakpoint, fire up the program, and take a peek at the program state at the point where the test fails in order to get an immediate and complete picture of what's going on in there.
d) Spend two hours stepping through the code one line at a time, and a further four on Google Image Search hunting for pictures you can use to pepper the blog post blaming the debugger you could stand to learn to use more effectively for your productivity problems.
You've got a unit test that just failed. It's not immediately obvious what's going on, but it's possible some assumption about possible states your program can be in at this point turns out to be incorrect. In order to diagnose it in more detail, would you rather. . .
a) Start guessing at possible causes, and cycle through iterations of writing print statements to check for them and then running the program to see their output until you make a correct guess.
b) Start guessing at possible causes, and cycle through iterations of writing Assert() statements to check for them and running the program to see if anything throws until you make a correct guess.
c) Set a breakpoint, fire up the program, and take a peek at the program state at the point where the test fails in order to get an immediate and complete picture of what's going on in there.
d) Spend two hours stepping through the code one line at a time, and a further four on Google Image Search hunting for pictures you can use to pepper the blog post blaming the debugger you could stand to learn to use more effectively for your productivity problems.
"Debuggers are not like washing machines where you can throw in your code and some soap, go get some coffee and watch TV, and then 30 minutes later the defect is removed."
IMHO this first sentence shows that the author has a false perception of what should a debugger do.
Above all a debugger is a tool to find bugs in your code, not a box fixing things with magic.
Having used extensively the Perl debugger (while debugging Perl, of course), I hardly see any other way to get shit done : you can put breakpoints in your code, see the value of your variables, and so on... largely more effective than putting print statements on the wild, or calling Data::Dumper.
When I think about the time I spent in the VC++ debugger tooling around through the MFC code to see what it was really doing as opposed to what I thought it was doing...
Yeah, bugs came from my "inability to understand the code under all program flows", or whatever, but it would have been considerably more difficult to understand the code without looking at it in use.
Yeah, bugs came from my "inability to understand the code under all program flows", or whatever, but it would have been considerably more difficult to understand the code without looking at it in use.
Like any tool it can be abused or used instead of trying to grok how shit works. There's an easy way to fix it: Don't do that. There. Done.
I pull out the debugger every now and then, just like I pull out an IDE when writing Java code, or the web inspector when running my javascript. Running stuff aids my understanding of said stuff.
Let's not try and run a one-legged marathon just for the sake it, shall we?