There's sure no better way to "become one" with a program, putting yourself "in its shoes" than running it inside an interactive debugger.

You might also like these tips and tricks;

• Putting the line kill 2, $$ will cause the debugger to break at that point in the source (on Unix, anyway). This works by emulating pressing Ctrl+C (it's the interrupt signal). This is great for setting breakpoints deep down in your code.
• If you ever turn strings into real functions via eval, then make sure to add a 'magic line number comment': eg,

  sub some_auto_generated_function {
      my $self = shift;
  # line 1 "some/preprocessedfile.foo"
      print $self->frop;
  # line 7 "originalfile.pm"
  }
  [download]

  If you do this, the emacs debugger will correctly step through the right source files. Sadly, though, the old perl5db.pl interactive debugger doesn't actually display the source properly.
• Devel::ebug is a brand new debugger that doesn't have a lot of the limitations of the old debugger, in particular the segfaults, but instead brings a whole lot more new Storable related ones! Joy! But, anyway, this debugger is client/server with a very lightweight in-program "server", so you can debug remote programs. If you could write an emacs-compatible communication layer for it, you could bring this debugging to the "next level" of perl debuggers, which might include the debugger for Perl 6.

$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/."
."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";
[download]

Putting the line kill 2, $$ will cause the debugger to break at that point in the source (on Unix, anyway).

I had never seen that trick before. Cool. I have been using this one instead:

$DB::single = 1;
[download]

That causes the debugger to enter "single-step" mode, which amounts to programmatically setting a breakpoint in the next executable line. This is particularly useful for causing the debugger to stop at places that happen before the first executable line, e.g.:

BEGIN {
  $DB::single = 1;
}
use Foo;
[download]

The code above will enable stepping through the loading of 'Foo', which otherwise would happen before the place at which DB normally starts (i.e. the first executable line). I see that kill 2, $$ works well for this too. One more trick for the bag.

the lowliest monk

It sure looks that way. I find it inexplicable... It's like writing Perl programs without ever using hashes: it is certainly possible, but why forgo the benefits of such a powerful tool?

the lowliest monk

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.

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

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.

There are no benefits. You're a dyslexic wondering why everyone isn't dyslexic.

    while (1)
    {
        print "$0> ";
        chomp(my $input = scalar <STDIN>);
        last if $input =~ m/^(q|quit)$/;
        my $res = eval $input;
        chomp(my $out = $@ ? $@ : $res);
        print "$out\n";
    }
[download]

It offers nothing that can't be done with DB, but the learning curve is a little less challenging.

In my own projects I'll have a "dbg" script which loads everything, sets up a few objects and leaves me at the debugger prompt:

#!/usr/bin/perl -dl
BEGIN { DB::parse_options("NonStop=1"); }

use B::Deparse;
$deparse =  B::Deparse->new();
sub code { return $deparse->coderef2text($_[0]); }
# p code ( \&Some::sub )

# Setup up env here

print <<'TIPS';
-----------------------------------------------------
instructions and defined variables here
-----------------------------------------------------
TIPS

DB::parse_options("NonStop=0");
[download]