in reply to Re: Re: Re: Are debuggers good?
in thread How to debug unknown dynamic code?
If you need to debug code, it's wrong. Start over. Redesign. Recode. Rethink.
...you know, I was with you merlyn until this statement. (And perhaps it's not fair to quote it in isolation, but certainly in that context, it seems wrong.)
I've listened to the debate in several programming "realities" and I have to agree with tye that most of the folks who are militantly "anti-debugger" are those who never took the time to figure out how to use this necessary tool. (And I know better than to think that this is the case for you.)
I must also point out that there are many (including myself) who will regularly waste large amounts of time single stepping through long sequences of code when it's not necessary. Probably I would have to say that I've wasted as much time with debuggers as I have saved by using them.
Like you merlyn, I seldom spend much time in the classroom telling students about the Perl debugger except for the context of using it as an interactive discovery tool from the prompt. I usually tell them that the best debugger on Earth is one that works with any programming langage you might need to use; It's the one between your ears. Techniques like print() statements and developing in small phases are the right way to go.
And yet there are legitimate reasons to use the Perl debugger and everyone should learn how to use at least 6 or 8 key tactics with the debugger. (And avoiding the debugger is like ignoring some of the tools in your box, never mind what rationale you present.)
I tell students about the danger of stepping through long sequences of code several times in succession as a mindless exercise merely because you can't think of what else to do. On the other hand, I tell students about those situations I (and others) have encountered in which as we single-step through the code, somehow the code looks different in the context of the debugger and an error which eluded our attention in the editor somehow speaks directly to us when we see it printed as the "next instruction to be executed" in the debugger.
And reliance solely upon the use of trace statements is sort of an "arms-length" approach to examining data. You have to think about what you want to see at a given juncture while you have the code in the editor. You are not gifted with the opportunity to ask arbitrary questions about the data as the code runs. For me, that's one of the great benefits of being in the debugger. It's the opportunity to say, "Wait a minute! What is this variable set to right now?" Sometimes you know what to ask in a print() statement and sometimes that only occurs to you if you can freeze time at the appropriate moment.
The bottom line is that "it's all good" and we can either use the debugger as yet another tool or we can avoid it. If you avoid it and are able to code successfully to completion, then you probably did not need it. But I think we can all agree that every Perl programmer should learn how to use the debugger effectively. Having done that, if you find that your normal pattern in the code-test-revise cycle doesn't have you invoking the debugger often, then that's "Just Fine(tm)!"
...All the world looks like -well- all the world,
when your hammer is Perl.
---v
|
|---|