[tpm] Seeking advice on using Perl in a professional way

[zoffix at zoffix.com]

Quoting Harold Tessmann <htessmann at control-tec.com>:

> Hi from Michigan! Apologies if that’s a little far away for the Toronto
> list, but the local pm.org mailing lists seems a little dead.

Welcome! A little dead in Michigan? Must be something in the water...

> I'm looking to productionize some Perl scripts, and as such, I want to
> adopt more structure than I use in disposable scripts. These scripts would
> be used within the bounds of my employer, not released to the general
> public (with maybe one or two exceptions). I know that TIMTOWTDI, but I
> like the “sometimes consistency is not a bad thing either” extension when
> it comes to common problems such as command-line option parsing, and the
> perldocs don’t go in depth on what people use in the real world. I’m
> looking for advice on topics including, but not limited to:

I don't know if your employer mandates which Perl to use, but I found
Perl 6 to be much more apt for command-line-parsing scripts and one-  
or few-liners
than Perl 5. It has much more concise syntax and comes with command line
parsing built in:  
http://linuxtot.com/parsing-command-line-arguments-in-perl-6/

> • Modern Perl: I like it in general, and I can install it on my team’s
> machines. Are there reasons I shouldn’t use it?

It doesn't really look like some must-have module to me. Feels more like
something opionated that's well-known simply because chromatic put it into
his book. I don't use it and you can make your own, more useful bundle of
stuff with https://metacpan.org/pod/Import::Into

>
> • Does anybody have a suggestion for a good blank script template? For
> instance, I know I want "use Modern::Perl 'version';" or "use
> warnings/strict;", etc., but there’s probably other things I would want in
> a basic script. I’ve handled this in a sort of ad-hoc manner, growing new
> scripts based on what I learned from the old, but I’d like to build a good
> template once and be done with it. I’d also like the template to include
> documentation, and that raises more questions. Is there a reason to put my
> pod block near the top vs. the bottom? Getopt::Tiny seems nice, including a
> feature to automagically build a usage block—should I use that or is there
> a reason to avoid it? Or is there a better option parser?

As mentioned, Perl 6! :) There's no boiler plate and sub MAIN does the arg
parsing and usage generation, so the entire template is just `sub MAIN () {}`
But if Perl 5 is your thing,
reused templates sound like a terrible idea. One day you'll end up editing
something in all of your scripts just
because part of your template needs a change. Use something like Import::Into
to collect all the modules you use into a single module and add some
helper subs into it. Then use just that one module in all your scripts
instead of a template, so if you ever need to make a changed, you'd only need
to change that one module once. And as Cees mentioned, it's much easier to
test the stuff as well.

P.S.: the improved version of `use strict/warnings` is `use strictures 2;`. It
fatalizes some of the warnings that usually indicate an issue in your script:
https://metacpan.org/pod/strictures

> Is there a reason to put my
> pod block near the top vs. the bottom?

Always put at the bottom. There's nothing worse than inter-mixed Pod  
and code when
you end up reading a script without a syntax highlighter. It's just impossible
to keep track of which chunk of code is code-code and which is just a  
pod code example.

> • Do you run Perl::Critic on your code? I know I’ll disable some of the
> rules, but is it more hassle overall than it’s worth? Similarly, PerlTidy:
> it seems useful for generating HTML versions of documentation, but I write
> code in a very precise way, such it would take more time to configure it
> than I would save in reformatting.

I don't, but I think I'm an exception. I prefer to manually make my  
code pretty
(some OCD examples of it:  
https://github.com/perl6/roast/blob/4ade099426/S32-io/indir.t#L65-L144  
).
I think PerlTidy has an option for doing that, at least in part.

> • Thus far I haven’t built anything complicated enough to warrant figuring
> out an object library; I can get by with basic hash-based structures. I’ve
> read a bit about Moose and Dancer: how do they compare? And what else is
> widely-used that I should consider?

Well, Moose is an OO system, while Dancer is a Web framework... so  
comparing them is apples and oranges.
Moose needs a C compiler, has expensive startup cost, and the scripts  
you described so far sound
like Moose would be an overkill for them. There's a "lightweight"  
version: Moo ( https://metacpan.org/pod/Moo )
and <*shameless self-promotion*> its cousin Mew (  
https://metacpan.org/pod/Mew ).

Moo is easy to pick up—the basics are no harder than stock, hash-based  
OO—it is
lightweight, needs no C compiler, and if you ever find you need more  
punch, you can
just swap Moo to Moose and the rest of your code should just continue to work.

Hope that helps.

Cheers,
ZZ