I find myself wanting to retort, but that's not the right spirit. My claim rather is that this fulfills Torvalds' criterion:

                                                                    
$ perl -d 1.debug.11.pl

Loading DB routines from perl5db.pl version 1.55
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(1.debug.11.pl:12):    my $ts          = "template_stuff";
  DB<1> c                                                             
+          
title is 1.debug.1
path1 is /home/hogan/6.scripts/1.debug.1
abs is /home/hogan/6.scripts/1.debug.1/1.debug.11.pl
debug1::make_initial_captions(template_stuff/debug1.pm:42):
42:      my $iter = $image_path ->iterator;
  DB<1> c                                                             
+          
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image3.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179:            my $next;
  DB<1> c                                                             
+          
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image4.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179:            my $next;
  DB<1> c                                                             
+          
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image6.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179:            my $next;
  DB<1> c                                                             
+          
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image1.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179:            my $next;
  DB<1> c                                                             
+          
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image5.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179:            my $next;
  DB<1> c                                                             
+          
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image0.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179:            my $next;
  DB<1> c                                                             
+          
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image2.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179:            my $next;
  DB<1> c                                                             
+          
return2 is nothing yet
ini path is /home/hogan/Documents/html_template_data/6.values.ini
...
return is 1.debug.15.html
http://www.merrillpjensen.com/perlmonks/1.debug.15.html
Debugged program terminated.  Use q to quit or R to restart,
use o inhibit_exit to avoid stopping after program termination,
h q, h R or h o to get additional info.
  DB<1> q                                                             
+          
$
[download]

All of the people you quote are elite professional programmers as opposed to the intermediate that I am, who makes useful software for his own communications, holding it all together with bubble-gum and tie-wire. I really like the price, too. Getting output adds to an already happy day....

Though I've never met Linus, I suspect retorting to him would be futile, given his parting shot was "Because I'm a bastard, and proud of it!". :) Update: It seems Linus is now a reformed character (from Organizational Culture (Part V): Behavior).

Based on the code you posted, I feel the most relevant quotes for you are from Pike, Martin, and especially Graham-Cumming:

I suspect that the same people who use debuggers all the time are the same people who don't unit test their code

and Conway:

fix the test suite first by adding tests that cause it to fail ... once the test suite is detecting the problem correctly, then you'll be able to tell when you've correctly fixed the actual bug, because the tests will once again fall silent

That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger. I suggest you at least consider the option of replacing hours of never-ending crack-pipe debugging sessions with enjoyable creative hours of Test Driven Development.

That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger.

I don't think there's ever a need to fire up the debugger. However, there are occasions where a debugger session might just be the fastest way to narrow down an error. Unit tests and the debugger are by no means an either-or decision.

I occasionally work on code written by someone who has retired. Code which doesn't have unit tests and/or isn't well designed and/or hasn't been touched in a decade or so. I could, of course, just argue it's not maintainable (merlyn). But when I'm interested in the code, I'd rather spit into my hands and grab whatever tools might help.

The quotes about tracing (merlyn) or stepping through a program (Brian Kernighan and Rob Pike) just miss the point about what debuggers can do. Personally, I'd rather use the debugger than print statements (Daniel Lemire) just because debugging sessions are transient (Brian Kernighan and Rob Pike). I don't want to spend time to format data structures for printing (the debugger does it for free), and I don't want to have to remove the print statements before committing.

I agree with most of the quotes that you need to think before starting to debug. But I also think that you need to know the debugger to some extent to decide whether it is a good tool to tackle a problem or not. Learning the debugger is not a waste of time, and it is easier to get started with than e.g. Log::Log4perl or Test-driven development.