You can count me in the "rarely use the debugger" school. I've always found using the Perl debugger is a process of frustration, I use win32 so it tends not to play nicely, but even when it isn't playing silly-buggers I still find it annoying. Its like inspecting a house through a keyhole, you never quite know how what you are looking at fits into the big picture. Ive also had far to much experience with code that has been "patched" from the debugger, and not well.

I think the issue is that the debugger tells us "what" and usually the real problem involves a lot of "why". Debugging with print statements IMO tends to promote a holistic view of the program. Its necessary to have a good understanding of the program flow and processes to debug this way, and I think overall this promotes a better quality of programming. If you need to step through your code in a debugger to understand why it isnt doing the right thing then I think its not unreasonable to argue that your code is too complex and needs to be rethought. And such rethinking wont happen while you are in the debugger.

I leave you with a quote by a famous programmer about why he doest much like debuggers. Admittedly the debugger/debugging he is talking about is kernal debugging, which is a somewhat specialized area but i think the points are valid nonetheless.

I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_.

It's partly "source vs binary", but it's more than that. It's not that you have to look at the sources (of course you have to - and any good debugger will make that _easy_). It's that you have to look at the level _above_ sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line.

which is an excerpt from this posting by Linus Torvalds.

You can count me in the "rarely use the debugger" school.

Me too, but for entirely different reaons. I work with a number of different languages and environments. Not all of them will have debuggers (eg: javascript on AvantGo browser). Even if a debugger is available, each language will have its own debugger model with its own quirks and idiosynchrancies. I found that using print statements and conditional statements (eg: print $foo if $DEBUG>3 ) to be good enough in most cases, and more importantly cross platform and cross language (ie. the technique is, the syntax will not be).

It's like writing Perl programs without ever using hashes: it is certainly possible, but why forgo the benefits of such a powerful tool?

Because some people find they get more benefit using other techniques. See Are debuggers good? for a long vitriolic thread on this very topic :-)

For example I personally find doing TDD a far more effective use of my time than spending time in the debugger. The mere fact that I need to drop into the debugger is a sign that I've fouled up earlier since I've obviously written code that is too hard for me to understand. The incidence of me using the debugger on my own code is as close to zero as makes no difference.

About the only time I use the debugger now is when poking at other peoples code and doing exploratory testing, or maybe trying out a one liner.

Snips from three notes above, with emphasis adjusted by me:

In my experience, most Perl programmers (in fact, most programmers) don't use the debugger at all.

but why forgo the benefits of such a powerful tool?

Because some people find they get more benefit using other techniques.

the debugger is a sign that I've fouled up earlier

About the only time I use the debugger now is when poking at other peoples code and doing exploratory testing

Do you see how you contradict your own argument and/or misunderstood the original point?

Using the debugger need not be a sign that one doesn't know how to write code well. I guess there are people who use the debugger as a crutch and spend hours single-stepping through code aimlessly hoping to understand what they did wrong. I assume that because I've heard several people complain about such. I've never seen that. What I have often seen is someone wasting a lot of time trying to track down a problem when I can tell that this type of problem is likely easy to explore in a debugger and I would have found the problem quickly using a debugger.

There are certainly stupid ways to try to use a debugger. And I still find that people who dislike debuggers are those who don't know how to use a debugger effectively. I like debuggers. I don't use them that often. But when I've used them, they were often invaluable. There are many bugs and non-bug problems that debuggers are not well suited for trying to solve. And sometimes it is hard to predict whether you've got a problem that a debugger will be useful against.

But the debugger is a powerful tool and there are a lot of people (in my experience, the majority of programmers) who have never learned how to use this tool well (or even at all).

- tye        

Do you see how you contradict your own argument and/or misunderstood the original point?

Let me see if I can better explain the point I was trying to make.

Unlike you I have come across many people who do use the debugger as a crutch and spend hours stepping through code aimlessly. I think we're both in agreement that this is bad (even if you've never seen the behaviour).

Like you I have also encountered people who waste a lot of time sprinkling print statements or similar around a bug that would have been quicker to track down with a debugger. I agree completely that this is bad, I'm just not entirely sure that immediately resorting to the debugger is the best solution.

I guess the problematic behaviour that I sometimes see could be characterised as Debugger As First Resort.

A lump of code does something unexpected. Developer cannot immediately see what caused the error by looking at the code. Developer drops into the debugger and steps through the code, spots error and fixes it. Problem solved?

Maybe.

The problem I've seen with developers who use debuggers like this is that it seems to encourage a narrow view of the code. With the extra context the debugger gives they can more easily see the problem so they forget the fact that initially they couldn't see the bug. The debugger becomes a tool than enables them to avoid the bigger issues of avoiding introducing bugs in the first place, and writing code that's easier to understand.

Rather than immediately dropping into the debugger I think a more healthy reaction to not being able to understand the code you've written is to go "Deity on a bike! I've no idea what that bugger does. Better make it simpler until I do understand it". If you get good at it then you will tend to use debuggers less and less since the bugs get more and more obvious.

And I still find that people who dislike debuggers are those who don't know how to use a debugger effectively. I like debuggers. I don't use them that often. But when I've used them, they were often invaluable.

I too like debuggers :-) I can use them effectively. It's just that I choose to use other techniques that I find more effective most of the time. tlm found it "inexplicable" that a developer would choose not to use a debugger - and that was the issue I was trying to address.

Avoiding the debugger shouldn't be like "writing Perl programs without ever using hashes". It should be more like writing a Perl program without using local. Most of the time you don't need it, but it's occasionally useful.

But the debugger is a powerful tool and there are a lot of people (in my experience, the majority of programmers) who have never learned how to use this tool well (or even at all).

Yes it is a powerful tool. I agree that some developers don't know how to use it well so they don't use it at all. However, if somebody has to use the debugger as often as they need to use hashes in Perl their time would be better spent learning ways to avoid adding bugs and increase code comprehension.

Rarely using a debugger is sometimes a sign that somebody has learned ways of writing less bugs.

There are certainly stupid ways to try to use a debugger. And I still find that people who dislike debuggers are those who don't know how to use a debugger effectively

I've seen you say this a few times and I really wish you would follow up with at least a brief description of what you consider to be effective use of a debugger. Since I'm not sure if my use and knowledge would be considered effective I find it hard to decide if my feelings about prefering a more analytical approach are justified. Could you please expand on some high level aspects of how you think debuggers should be used? I think I've gleaned that you consider stepping through code to be a bad approach (I tend to agree) but I havent seen much more than that.

cheers

---
$world=~s/war/peace/g