http://www.perlmonks.org?node_id=48606


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

I'm amazed at how many people "just add prints" when they need to debug. I believe this has to do with not wanting to take the time to learn how to use the debugger.

Even if you only want to "just add prints", then you can use the debugger to simply add prints dynamically.

And using Data::Dumper to debug? I find an interactive "x $obj" requires much less typing, gives me a chance to look at related data if $obj shows something interesting, lets me change $obj to test if a suspected bug fix will actually get the proper output (often allowing me to fix more than one bug in a single run), doesn't force me to either page through lots of debug output nor try multiple runs trying to get the debug output right, and on and on.

If you've never used the Perl debugger for debugging, I urge you to give it a try the next time you need to debug.

I guess I've been "blessed" by having to track down non-trivial bugs that would be horrible to find by just adding trace so I've always managed to learn how to use the debugger for most of the programming environments I work in for very long.

I just can't believe that the process of "Gee, which things should I print out in the debug trace..." or the effort of printing out "everything" and then slogging through the output is more appealing or more efficient than setting a break point at the place were you wanted the trace and then just typing "x $x,$y", "No, those look right", type "|x $obj", "Hmm, why is 'color' undefined?", etc.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re (tilly) 2: Are debuggers good?
by tilly (Archbishop) on Dec 28, 2000 at 17:40 UTC
    I just can't believe all of the people who use debuggers who think that people like Randal and I are just taking a position out of ignorance of how to use a debugger!

    Follow through the thread of discussion in the conversation that I pointed to. The exact issue of Kernel Threads under discussion which I pointed to is here, check out sections 1 and 4. In particular the following posts stand out as being particularly relevant. First the one where Linus says, "I am a bastard, and that's OK", and IBM's experience.

    Both of those articles are written by competent programmers with years of experience developing in a very complex environment who both know debuggers. Both claim that while debuggers look easy, neither think that they really help. If you read those threads you will find many competent people who absolutely disagree with that position. There are people on either side.

    Note that I didn't say that debuggers are useless for debugging. I said I am constantly amazed at how many good programmers don't like them for that purpose but have plenty of other uses. It should be obvious that good programmers who have found other uses for a debugger actually understand what they are and how to use them. Ignorance is not the reason for not choosing to use them.

    No, the reason is more subtle. The limit to our ability to develop interesting things lies in our ability to comprehend. Debuggers focus intention at the wrong point. They let us blindly trace through code to find the symptoms of problems. That doesn't help us one bit to notice more subtle symptoms of structural problems in the code. It doesn't help one bit in giving us encouragement to be more careful. It doesn't encourage reflection on the process. It doesn't give us reason to think about the poor schmuck that has to handle our code afterwards.

    In short it encourages missing the forest for the trees. But in the end projects are felled by overgrown thickets, not by single trees.

    Now I know you will likely disagree. This is an opinion which many people are divided on. But my opinion just happens to be shared by a lot of very competent people. It isn't based on ignorance. Instead it is based on experience and thought about the process. I have repeated this point to plenty of friends. Some make you go, "hmmm". Like the guy who said, "That is true. I have written debuggers. I used to use them all of the time. But then I thought about my own thinking process, and tried not using it for a bit. After that I never looked back."

    However one thing we will both agree on. If you don't think about your own development process on an ongoing basics, then there is no question that a debugger would be helpful. They are effective tools, no question about that.

      I don't know you, tilly, nor merlyn. Most of the programmers I know that won't use a debugger for debugging don't know how.

      My point was that if you want to debug by adding trace output, then you can do that very well with a debugger (and I think you can "add trace" much more efficiently with a debugger -- though adding the trace during development and being able to enable it in production is an even better idea that still doesn't eliminate the usefulness of a good debugger). So I don't understand the argument that you don't use a debugger for debugging because instead you do it by adding trace.

      <rant>
      And I do disagree with the undertext that using debuggers means that a programmer isn't being careful up front or that it leads to programmers who aren't careful up front. I find more bugs in other people's code than in mine, even when debugging my own code. I spend a great deal of time figuring out how to work around other people's bugs because I don't have the option of fixing them even though I've found them.

      I do wish that other programmers would be more careful (as I talked about previously in (tye)Re: Why, not How). I don't think (as Linus seems to) that taking away debuggers will have any positive effect at all. That would just mean that when bugs crop up (which never happens to tilly nor merlyn because they are careful, despite having seen several of their bugs myself), more time will be spent tracking down that bug so there will be less time for improving other aspects of the software.

      I really doubt that it will be possible to remove many bad programmers from the profession (no matter how hard we manage to make programming). A bad programmer with a debugger still wastes plenty of time and has lots of motivation to be more careful. In fact, I've seen use of a debugger help a bad programmer learn how to be a better programmer.

      Never attribute to laziness what can be explained by ignorance. I think that most bad behavior that is blamed on laziness (or not being careful) has more to do with ignorance.

      [Debuggers] let us blindly trace through code to find the symptoms of problems.

      See, you think you know how to use a debugger but that statement tells me that you really don't. I never debug with a debugger by blindly tracing through code. My word, that would be a huge time sink.
      </rant>

              - tye (but my friends call me "Tye")
        Please step back before ranting.

        I have bugs. Of course I have bugs. When I post stuff off the cuff here I have a lot of bugs. Particularly when I post stuff that I didn't run, let alone test like I do before checking stuff into CVS.

        I don't know anyone who doesn't have bugs.

        Now please read what you responded to. Again. Without jumping down my throat first off.

        When I say that debuggers allow us to blindly trace through code to find the symptoms of problems, I am not saying that that is the only way to use them. I am creating a caricature of the tendancy I don't like. When you use a debugger to find a problem in your code, you do indeed find the answer to that specific problem faster. But you lose an opportunity to review your logic and clean your code up, which can often solve more bugs and helps in comprehension. With the convenience and immediacy of a debugger, the details of what is happening are too handy and the thinking about why someone might not want it to be that way are too distant for my taste.

        In short, I don't mind having to work harder for most bugs if it means that I get to program in a way where I wind up with fewer bugs in the end. Particularly since I have a lot of error checks which mean that if something does go wrong, I usualy have all of the information that I want immediately available. And if I don't, well that usually means that something more serious was wrong.

        Besides which the ease of using a debugger can mask important warning signs. Warning signs that I would like to see.

        Now as for Linus, while I see what he says, I likewise disagree with his position but for rather different reasons. Linus has been (IMO rightly) accused of suffering from The Curse of the Gifted. I think that applies here, he is underestimating the value of a tool for people who are not in his situation. In particular read again IBM's experience and look at all of the things that debuggers are listed as good for there. Yes, I think that a kernel debugger would be good. It would help people learn how the kernel works.

        Note that all of my statements about not wanting to fix problems interactively don't mean that I don't think it isn't a great idea to learn from running stuff interactively. Just because Linus doesn't need to learn how the Linux kernel works doesn't mean that others wouldn't benefit from that! And it can be useful to step from time to time through fresh code...

      I particularly like Linus' statement in that post:
      Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds callous, and by God, it _is_ callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's darwinism in software development.

      It's a cold, callous argument that says that there are two kinds of people, and I'd rather not work with the second kind. Live with it.

      I fully support that. There are far too many people who (attempt to) perform programming as a income activity who aren't really programmers. If you can't program careful enough to not need a debugger, then either slow down your rate of coding, or pick a different profession. Please.

      Thanks for the reference, tilly. That's the point I was trying to make earlier. I don't use a debugger, because I try very hard not to need one. {grin}

      -- Randal L. Schwartz, Perl hacker

        There are far too many people who (attempt to) perform programming as a income activity who aren't really programmers. If you can't program careful enough to not need a debugger, then either slow down your rate of coding, or pick a different profession. Please.

        This is, of course, true. There aren't enough real programmers around to cover all the programming jobs. And as the demand for IT staff increases the problem will only get worse.

        I was contemplating starting to run Perl courses in the UK, but perhaps I should just run programming courses first...

        ... or perhaps "programming" isn't something that can be taught.

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

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

      tilly,

      I'm not sure I read that the same way you may have. I thought tye was sharing some of the tricks learned while working with the language. While it's possible to interpret some moral judgements (to borrow a phrase elsewhere in the thread) from the post, I don't see anything specifically suggesting that you or merlyn are taking positions from ignorance.

      Perhaps that's my own judgement peering through.

      Regardless, it may be worthwhile to borrow a another concept from the monastic disciplines that inspired this site. Specifically, each travels their own path toward mastery.

      I don't use debuggers personally for many of the reasons cited in both camps. However, I do use them when necessary. They can be effective tools, but they should not be the only tool in your problem solving arsenal.

      In the end, we make choices by bringing our experience, knowledge, and creativity to bear on the problem at hand. Even bad choices can help illuminate the path.

      --f
        We definitely did read it differently. I was explicitly saying that I don't use the debugger for debugging, and in response to that tye answered saying that he thought that people don't use it because of not wanting to take time to learn to use the debugger. He went on to tell me to use one the next time I need to debug. Despite the fact that I am saying that my not using one is intentional.

        I read that as his not paying attention to what I said (the fact that I am making an intentional choice) and assuming that if I am exposed to the joys of debuggers then I (being a presumably sane human being) will convert.

        That is what I reacted to, and I don't think that I reacted particularly unreasonably to it.

Re: (tye)Re: Are debuggers good?
by vladb (Vicar) on Jan 11, 2002 at 13:06 UTC
    Let me concur with your statement and add a few cents on my part. I too started out with 'just print statements'. And, oh boy, it was getting on my nerves many a times. I did print statements since the very first time I started coding (at age 13 I believe) with BASIC. I then used prints in Pascal code (I didn't have a good debugger back than). Even when I moved to C I used prints. In many cases it's 'alright', but nothing more.... just about 'alright' to use. However, (and I assume for many it would seem like a mute point) I didn't find putting random (well, at least the first time I need to work on a piece of code that I've never 'debugged' that way before) print statements as helpful and efficient as setting a few breakpoints throughout my code and letting the program run until these points are reached. The problem that I experienced with the print statements was that I'd always have to re-run the code a number of times to just get my print statements placed in the right place and output just the right stuff to get at the root of a bug. This wasn't good for me. Recently (when I started working full-time) this wasn't good for my boss since I found myself wasting too much time playing with prints etc (on systems exceeding 30,000 lines of code in particular).

    So, a few years back when I first started with Perl, I thought that this is the one language where I'll try to do it right (and different!) When I had my first look at perl interactive debugger, I immediately thought "Who in the world could you such a horrible and complex tool?!". Well, to sum up, I was utterly wrong. Once I played with it a bit more, I figured that it was more useful to my productivity as a programmer than my old limbo with prints etc. I frankly find it hard to understand marlyn and others who say that doing away with prints is much easier. See, I was in your camp at one point as well. However, how easier could it be to simply place a few break pionts in your code and let the program run until these points are reached and do your testing (on 'faulty/suspicious' data) right there, poke it around, execute different variants of a program statement that you suspect might have a bug, etc. There's really that much use in a debugger. Now, I'm not even talking of those point and click debuggers. I don't like those in particular. However, perl's interactive debugger (where I can get away with not using my mouse) is superb for many debugging needs one might have. It's pretty quick.... there's much I could say about various debugging techniques that the perl debugger allows for and that I've come to appreciate.


    "There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
      You appear to be missing the main point of the overall thread.

      Debuggers find bugs and hide larger scale design issues. I am willing to put up with pain in solving specific stupid bugs if it gives me more of an opportunity to keep my overall design clean. Many excellent programmers agree. Many others disagree. But it isn't a trivially wrong choice.