When I came back to Perl after about four years of working primarily in Python, this was the first question I asked, in the form of "How do I make my scripts testable as a library while also runnable as a command?"
It wasn't immediately apparent how to do it back then, and it took a little explaining to even get people on the same page about what I meant. But, it was a really nice thing in Python that I immediately missed when coming back to Perl. You don't need to know the word "modulino" to do it, though.
brian d foy first talked about the idea in Perl well over a decade ago but it was already common in Python (and probably other languages, Python is just where I saw it first).
"In the Python world it is quite straight forward to make files work either as executables or as modules. In Perl it is a bit strange, but doable.
brian d foy has written a number of articles about Modulinos, but in nutshell a Modulino is a Perl file that can act both as an executable (a script that you would invoke directly) or as a module (Something you load into memory and expect to execute code only when you call one of its functions or methods)."
Just to add...one of the big reasons to do this is that testing that script now becomes much much easier as it is now a "module" and all the testing facilities in Perl can be brought to bear on it.
I still use 5.10 because that's what ships with CentOS 6 and my products will continue to support CentOS 6 until it reaches EOL. I think it'll be very common to target 5.10 until CentOS 6 dies. Any of my Perl code, even code written today, would include this line. I don't think it places the article in time.
As an aside, Red Hat, for a long time, would ship old Perl versions in RHEL, even at the very beginning of the RHEL version lifecycle. Which meant you would be stuck with a truly ancient Perl version by the time the RHEL version reached end-of-life. I mean, 5.8.x was already several years old when it was settled on for RHEL 5, and was EOL by the Perl community for a couple of years while RHEL/CentOS 5 were still shipping it.
RHEL/CentOS have gotten a bit better about it in recent years, I think because there are some folks actively maintaining Perl packages for Fedora and those trickle down into RHEL/CentOS, so it's not quite as bad as it used to be, but we still end up stuck with pretty old versions for the last couple years of a RHEL/CentOS release, which is annoying.
There are, of course, good options for building/maintaining newer versions for your own development or deployment in hosted app deployments (plenv, perlbrew, etc.), but if you want to be able to run with minimal dependencies and no requirement that end users install a whole new Perl, you will still `use 5.010;` instead of something newer.
I'm not arguing against backwards-compatibility; but pointing out the technique in the article has been around for a while since it was first written 7 years ago.
2. This technique is often used to guarantee minimum version requirements of a piece of code. No reason to lock your code to the latest version of the runtime if you know it requires features from an older one.
Perl v5.100.0 required (did you mean v5.10.0?)--this is only v5.26.1, stopped at modulino.pm line 3.
BEGIN failed--compilation aborted at modulino.pm line 3.
https://web.archive.org/web/20150227080722/http://www.master... is about the module Modulino which allows scripts to use these tricks.
DrDobbs had it 2004: http://www.drdobbs.com/scripts-as-modules/184416165