I take great offense to your insulting generalisation. I use the debugger all the time, in addition to significant amounts of tracing. And, unless you're willing to back up your assertion that since I need the "advanced" debugging tool, I must be stupid, I'd really appreciate it if you'd strike that out of your original post.

I find the debugger, even the text debugger, invaluable. Mainly because I can much more quickly find my problems than with print or logging (which I use as well). The print statements can help me narrow down a problem, but once I get to a certain point, I find it way faster just to set a breakpoint, continue to that point, and then I can look at variables, object method output, stack traces, etc., really quickly. I don't always know what I'm looking for when I get there, but I know I'll be able to query anything I need at that point. I can even run perl code (object methods, for example).

The problem with print, for me, is that I need to know what to look for before I get there. And since some of my perl code literally takes hours to complete, if I'm debugging something near the end, I want to get there as few times as possible.

I've also devised some infrastructure that allows me to bypass unneeded portions of the code - but it still can take 10 or 20 minutes to reach the point I'm debugging. Adding another 10 or 20 minutes each time I think I need more information is actually painfully slow, whereas with the debugger it'll take me 30 minutes to get there once (debugger is slower than regular code), and I usually don't need to go in a second time.

To me, there are some similarities between goto and the debugger. You need to really understand the breadth of the debugging tools to be able to use the right tool for the right job. When you understand how to use the debugger, it can be powerful. But when all you have are print statements for debugging, everything looks like a variable - you may get the job done, but it may have been faster/easier if you used the debugger.

Assuming you structure your program well and test properly at each stage,...

...and assuming that you wrote the !*#$$^!! code in the first place.

It's the stupid programmers who need advanced debugging tools,

I don't mind when people say "I never use the debugger...I just use print statements", that's fine if you never get into the situation where a debugger would tell you what you need to know without adding a single print statement, in fact, I just add print statements most of the time. But to call programmers stupid for using a debugger, is, well, stupid. At a previous job in a non-perl environment, I found it was the stupid programmers who didn't know how to use a debugger and spent days looking for a problem that I tracked down in a couple of hours with a debugger. When I was playing with AI::Prolog, I'd see code like $object->$method, and the easiest way to trace it was to fire up ptkdb and just step through that line of code. If you have the luxury of only ever working on your own code, then good for you, but don't go insulting those of us who don't.

If your design is perfect, and your testing is perfect, there are no bugs in your code, by definition. :-)

Let's say you're debugging, and you're adding a bunch of print statements. And you keep making typos, and having to fix them, and take them out of code before it hits production, and so forth. And it's becoming a pain, and one day, you wake up, and realize that all your debugging code may itself contain bugs. Otherwise, you won't be able to find your bug properly.

One way to attempt to avoid bugs in debugging code is to limit the complexity of code you write, so that you only write simple debug and trace statements. Unfortunately, you don't know before you run the program where the problem lies, so you don't know for sure what to print out: and printing everything will often drown you in a sea of output.

Wouldn't it be nice if there were a known, tested, and reliable set of debugging code that you could use? That way, you wouldn't have to worry about typos in all those darned print statements screwing you up; you would be able to get just the output you want, as soon as you decide you want it, without having to re-edit and re-run the program over and over and over again!

You'ld never delete a line of good code while trying to strip out all those print statements you added during the exploratory stages of your debugging. You'ld never let a debug statement slip into production. You'ld get the busy work of writing the same old lines of code over and over out of the way, and just concentrate on finding a fixing bugs.

Doesn't that sound nice?

Well, that's called a "debugger", and to me, that's why it's good. It lets you do the same thing that you do with print statements, except faster and easier, and it shields me against a few common kinds of stupid, time consuming mistakes.

It guarantees that I didn't screw up a program by testing it. If you hand test my code by editing it to understand it, but claim you've made no functional changes, and then later my code breaks, the boss doesn't know which one of us really broke the codebase. If I test using the debugger, the boss knows it's not my problem, without auditing the codebase for changes and arguing over who changed what. It's one less set of diffs to run... one less thing to think about.

Single stepping through the entire program is rarely the answer, but verifying the functions down the call tree is a quite reasonable way to track down a bug.

Does the main program work correctly? No, because you're hunting a bug. Follow the following steps, and you'll probably discover your bug:

1. Look for the design flaw or coding error at this level of the code. If you see it, you're done.
2. If it's not here, look at the output of each of the subroutines called. One of them should be wrong (the bug is either at the level you're looking at, or further down).
3. Step into the subroutine that's in error.
4. Goto step 1

You can do this same thing without a debugger, but it involves writing more code, and you have to re-run the program over and over. Debuggers run code a bit slower, but you don't have to write code to see what's gone wrong, and you can change your breakpoints (ie. where you put your print statements), and what you output as you go.

It's the stupid programmers who need advanced debugging tools, and they're the ones who won't understand how to use them :)

I personally think it's kind of foolish to avoid a tool that can solve my problem faster, but to each their own. Maybe I'm just a "stupid programmer", but again, I think my boss cares less about my IQ, and more about whether I can solve the problems that make his business run. To me, a good program is one that solves the job at hand, correctly, in the budget allotted, with an eye to future business needs.
--
Ytrew