http://qs1969.pair.com?node_id=48629


in reply to Re: Re: Are debuggers good?
in thread How to debug unknown dynamic code?

I wonder if a lot of your opinion stems from the kind of coding that you do merlyn. Seems to me that you're lucky enough to be able to work on your own code most of the time. And would it fair to say that most of the programs that you write are small demos of particular Perl features for training courses or articles?
Nope, this is 22 years of professional experience talking. While it's true that a good portion of my programming activity for the past two years has been original solo work and small-to-medium programs, I speak also of the times when I was writing very large programs and systems (tens of thousands of lines of code) and working with other team members. Never used a debugger then either.

And if the code the client throws at you needs a debugger to trace it through, I'd argue it's not maintainable, and should die the death it deserves. I can't tell you how many pieces of code (or entire programs) I've just simply thrown away and rewritten.

As an example, did you ever step through the printf in the C library? No? Why? Because it's well-written, and you can understand it from the specification. If the code your client throws at you doesn't work like that, then kill it. You can't patch a Yugo into a Porsche. Ever.

To do any less is to sell out for dollars. Unethical, in my book.

If you need to debug code, it's wrong. Start over. Redesign. Recode. Rethink.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
Re: Re: Re: Re: Are debuggers good?
by davorg (Chancellor) on Dec 28, 2000 at 20:41 UTC
    And if the code the client throws at you needs a debugger to trace it through, I'd argue it's not maintainable, and should die the death it deserves. I can't tell you how many pieces of code (or entire programs) I've just simply thrown away and rewritten.

    This is the final fate of much of the code that I see as well.

    Of course, then you discover that there's no spec for the program and the person who wrote it left three years ago so the only way to rewrite it is to work out exactly how it works - and suddenly I'm back in the debugger :)

    Maybe I need to choose my clients with more care!

    --
    <http://www.dave.org.uk>

    "Perl makes the fun jobs fun
    and the boring jobs bearable" - me

Re: Re: Re: Re: Are debuggers good?
by agentv (Friar) on Dec 30, 2002 at 09:23 UTC
    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