in reply to Using the perl debugger to look at a renaming files function

Though you've watched the Ricardo Signes How to use the Perl debugger talk twice (while I've not yet watched it once) I'd just like to throw a general word of caution that becoming an expert in using the Perl debugger may not be the best use of your time if your goal is to improve as a developer.

A few debugger quotes from some famous programmers:

Updated: Added Damian Conway final bullet point.

  • Comment on Re: Using the perl debugger to look at a renaming files function

Replies are listed 'Best First'.
Re^2: Using the perl debugger to look at a renaming files function
by Aldebaran (Deacon) on Feb 06, 2021 at 01:02 UTC
    Linus Torvalds : I do not condone single-stepping through code to find the bug ... Without a debugger you have to look at the level above sources. At the meaning of things. You have to understand what the program does. Not just that particular line.

    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 + $

    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!". :) 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.