Re: Use Getopt::Long even if you don't think you need to

[grinder]

I must say was rather surprised by that remark. It's worth spelling out in full:

What seems to happen is that at first we just want to add--oh say for example JUST ONE, SINGLE LITTLE -v flag. Well, that's so easy enough to hand-hack, that of course we do so; maybe like this:

    if (@ARGV && $ARGV[0] eq '-v') {
        $verbose = 1;
        shift @ARGV;
    }

I couldn't believe anyone (still?) reasons this way. In the case of command-line arguments, I find this line of reasoning is unconscionable. Sooner or later, and likely sooner, there will be a second option, and at that point, if you don't refactor you have just doubled your technical debt.

Similarly, Larry's remark about not using a Getopt::* library because it didn't seem worth the bother to load it in for just an opt or two to be a bad case of premature optimisation.

I'm happy to cut them slack because twenty years ago, people didn't know any better :) But in this day and age there is absolutely NO reason for rolling your own command-line processing. Any more than no-one should be decoding CGI paramters manually.

[Aristotle]

It’s nothing to do with not knowing better, and much to do with the fact that 20 years ago computers were far more limited. Even today, in a script that generates submenus in my window manager’s root menu and is run every time I hover over the submenu item (and therefore needs to launch, run, and terminate instantly), I had to use Getopt::Std over Getopt::Long because the latter just plain doesn’t load fast enough. Similar concerns exist when writing CGI scripts, which is thankfully a genre in decline. Another related issue might be memory use – big modules eat more RAM just for being loaded.

Put in context as an anachronism, Larry’s justification seems a lot less irresponsible.