http://qs321.pair.com?node_id=48579


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

I'm not into debugging. I can't recall ever invoking the Perl debugger except to try out snippets of code at a prompt (for which I type perl -dead usually), or in class while I'm trying to teach the debugger (which I do poorly, since I don't "debug" my code with a debugger). But never for debugging. (Larry is also like this, I'm told.)

So the question is, what do I use to debug?

Well, the first answer (and most important answer) is that I don't have to debug what doesn't contain bugs. Don't put bugs in. That's easier than it sounds, if you code in small chunks, slowly adding code one understandable step at a time. Never type anything into a program if you can't completely run it in your head.

The second part of the answer is that I started programming long before we had all these fancy GUIs and drag-n-drool debuggers. So when I had code go off the deep end, all I could do is keep adding print statements until it worked. As I got better, the number of prints got smaller, and then eventually I could just code the whole thing without adding any debugging.

With Perl, I throw in a random "die", sometimes with the result of Data::Dumper::Dumper in its mouth, but that's usually only once every five or ten times as I extend the program.

So what's all this about a Perl debugger? Why do people use it? Have they not learned the more effective ways of never letting your code get ahead of you, and trying to reduce the problem to something a die can show you? I'm truly puzzled.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
Re: Re: Are debuggers good?
by davorg (Chancellor) on Dec 28, 2000 at 18:14 UTC

    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?

    If I was writing programs under those conditions, I don't think I'd have very much use for the debugger either. Unfortunately, I don't work like that. I spend three or six months on a client's site and the first thing they invariably do is throw a piece of the most horrible Perl you've ever seen at me and ask me to either fix or enhance it. In cases like these I find that running the code through the debugger is an invaluable way to get an in-depth look at exactly how the progrma works.

    I think that not enough people use the debugger. I think that this is often because Perl programming is seen as 'scripting' and not important enough to justify that level of work. I further think that this point of view is completely wrong, but that it explains a lot of the very dodgy Perl code that you can find out there.

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

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

      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

        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

        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

Re: Re: Are debuggers good?
by chipmunk (Parson) on Dec 28, 2000 at 09:06 UTC
    I'm somewhat offended by your characterization of people who use the Perl debugger for debugging. One could just as easily look at it from the opposite viewpoint:

    What's all this about debugging with print statements? Why do people do that? Have they not learned the more effective ways of using a real debugger? I'm truly puzzled.

    As I see it, the only advantage to print statements is that they're simple to use. An actual debugger is better in all other aspects.

(jeffa) Re: Re: Are debuggers good?
by jeffa (Bishop) on Dec 29, 2000 at 03:34 UTC
    Oh how I concur - actually, I was quite shocked to hear this coming from you, merlyn - no particular reason.

    When I was studying CS in college, I was a lab assistant. I learned very quickly to code in small chunks - and save often - revision control was also a big plus.

    I learned this, but most of the first and second year CS majors refused to work in this manner. It was a shame to watch them type about 100 lines of code, try to compile it, and then ask me to help figure out what these 200 lines of errors meant.

    <CONTROVERSY>
    To tell the truth, the only debugger I found helpfull is the one that is available for Visual Basic.
    </CONTROVERSY>

    Jeff

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    F--F--F--F--F--F--F--F--
    (the triplet paradiddle)
    
Re: Re: Are debuggers good?
by extremely (Priest) on Dec 28, 2000 at 10:07 UTC
    Two Whoops for this. I've never found the debugger to be remotely useful. The pain of using it outweighs the value. I use the debugger to understand behavior of code or algos, I use prints or warn logging to find bugs when I'm too lazy to refactor the code that got out of hand.

    About half the time, I just rewrite the section in multiple pieces and the bug "goes away". Heck, I rarely open the debugger on _C_ code unless I need to find out what was on the stack at a core. Perl is ever so much better than that, I just can't imagine that it is very useful.

    Update I wouldn't go so far as to say that gdb rocks my world but it has sure made working with big bad C quite a bit easier. Still, I usually don't pick it up will there is a nasty problem.

    --
    $you = new YOU;
    honk() if $you->love(perl)

      If I'm writting C or C++, then gdb rocks my world.

      Seriously, I took the time a couple of years ago to learn how to use gdb with Emacs and I've never looked back, it has made my life soooo much easier.

      Bearing in mind, that this was when I was working on my B.Sc and we did lots of nasty stuff with pointers. However, when I think of how much the people who didn't know gdb struggled with finding bugs, I'm glad I learnt to use it.

      I still use gdb on a regular basis. I've been meaning to learn to use the Perl debugger just as well, maybe it's time to try and track down an Emacs mode for it...

      To set aside the holy war, I use Emacs for programming and vi for general editing of text files...

Re^2: Are debuggers good?
by osunderdog (Deacon) on Jul 27, 2005 at 12:22 UTC

    I occasionally use the debugger for verifying small programs. However in large systems, rather than printing program information to stdout, I use a log file framework to capture diagnostic information. By using a log, you can capture information over time. Of course like print statements, there is an art to adding log statements at appropriate times.

    I remember having a heated discussion with a 3rd party equipment vendor that started with me asking why they didn't produce logs. It finally came out that he didn't think that logging was a legitimate diagnostic tool because the technique is never taught in school. He encouraged his developers to use the debugger whenever possible to diagnose problems. I can tell you for a fact that their code was extremely buggy. It would take several hours of runtime before the bugs would propagate enough to affect the overall performance of the system.

    The problem with debugging is that it can only give you information on how a program is running at an instant. That may be acceptable for a CGI that gets restarted every few minutes, however it won't help you find a creeping memory leak that appears over the course of 200 hours. Printing or logging, if done correctly, can give you information on how a program is running over days, months or years.

    Holy cr@p I'm still Unemployed!