Are debuggers good?

[tilly]

A while ago on another site I had an interesting discussion on exactly this topic. I find it amazing how many good programmers have all sorts of uses for interactive debuggers - but say that debugging is not one of them! It certainly isn't for me. And in this problem in particular, the code you are describing sounds like stuff which I would suggest that you not use a debugger on.

So how would I approach this problem?

First of all I would use strict. If his code cannot readily be cleaned up to pass that, then he is likely doing some nasty stuff. I would prefer to rewrite than maintain dynamic symbolic references.

Otherwise I would then step back and set out to understand the code on a conceptual level. It will take a while. But that is the main problem with debuggers - they make you think about problems at too low a level.

Now you say you cannot check his code out. Do you have a development environment that is separate from production? If so then develop in that. If not then tell the rest of us where you work so we know to avoid the company, then try to figure out how you can set up a small test environment.

If you can't do that, then read the code anyways. And let this be a lesson for you in the future. Don't use stuff that you don't really understand which you are not completely confident about... :-)

[tye]

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")

[tilly]

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.

[tye]

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")

[merlyn]

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

[footpad]

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

[vladb]

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

[tilly]

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.

[merlyn]

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

[davorg]

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

[merlyn]

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

[chipmunk]

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]

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)

[extremely]

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)

[puck]

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...

[osunderdog]

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.

[Maclir]

I have not used a debugger for perl code, but I have used them in the past. Particularly in OO programming, where there are a heirarchy of classes, it is good to step through a particularly troublesome piece of code to see if it is doing what you though it should ("Hmmm - someone is not playing the cards I dealt them").

Several years ago, I developed systems in Gupta's SQL Windows. The built in debugger was powerful - and very useful.