Perl 5 is alive and well thanks to the CPAN. Without the CPAN, it's an interesting language with some great features and some flaws. With the CPAN, it's a toolchest full of precision instruments that good programmers can wield to make great things.
For all of the flaws
with Perl 5's
import() mechanism, the compilation-time
import() led directly to the creation of and
growth of the CPAN. Libraries will happen without explicit language support,
but explicit language support in Perl made something amazing and transformative
I use Perl because it's so very well tested and verified. In fact, I believe that Perl's testing culture has no parallel in other languages. In a very real way, the entirety of the CPAN is a smoke testing system for the core language development.
Unlike big-A Agile, which is a morass of training and certification and books with too little focus on delivering successful projects or little-a agile which is like flossing: something everyone says they do but you know only happens a couple of times a week, at most, Jim's test-driven development gets done and actually works.
Reduce Technical Debt
(alternate heading: Reduce Crazy)
Sometimes you have to keep around the cruft, but you can't limit yourself to what was valid in old code if it will prevent you from producing new code.
Even if the semantics of features change, the surface syntax of the language can upgrade slowly and deliberately if and only if programs written in the language make explicit their requirements.
Put another way, HTTP makes you say
HTTP/1.1 for a reason.
automatic semicolon insertion) and add missing features (trailing commas in
list literals, library use and dependency management, namespacing) with a
strategy like this. For as much as I dislike
"use strict" as a
magic string constant, at least it works.
For as much as people complain that even decent Perl code can be inscrutable, Perl has copious internal documentation (see perldoc.perl.org for an online version of the docs which you most likely already have installed on your machine right now). The CPAN also has strong cultural guidelines for how to document modules and distributions. Even though these are community guidelines, projects adhere to them.
(I have lost track of how many patches I've sent to rephrase an unclear piece of documentation or add something missing or even to fix a typo; thank goodness for Git and Github, I say.)
Building a culture of communication and documentation is not easy, but the results are wonderful. I expect that any good library I use in Perl has decent tests, has a working installer, and has at least basic API documentation. I'm rarely disappointed.
I could write more about community management and expectations, but that's a non-technical subject with fluffier answers you can guess at anyhow.
Who knows? Maybe together we'll make programming easier, more pleasant, more reliable, and even more secure.