Recently I was reading this article on how Lisp sucks, and I was thinking how one could just do s/Lisp/Perl/g and have it be true. Then I re-read again and wasn't so sure. Perl core does advance and improve, modules can be written to extend its functionality, or even make Perl code not look the slightest bit like Perl. (See Method::Signatures, MooseX::Declare, and Moose itself).
So what are the major shortcomings of Perl? Maybe its the fear of the darkpan. We can't change anything because it might break the enormous pile of perl code out there that we don't know about. chromatic wrote so aptly that upgrading should be done conciously, and with care. If your code is fine and in maintenance mode (not actively being developed, but still doing its job), why upgrade?
This is where I see Perl having two aspects. There are the set of Perl applications which have been conciously planned, may/should use their own Perl binary, own install of needed Perl modules, etc. Those apps can indeed decide when to upgrade and when not to. But what about the other uses? Perl is often used to write scripts, to stick in a cron job (scheduled task), and not thought of again. They'll rely on the system Perl, and probably use system-wide installed modules. I almost wanted to call this "two cultures", but since the same people use Perl in these two different ways, thats not really correct, or is it?
I wonder if we can help cater better for this second Perl use? (The original one, before Perl grew up). For example, a perl file can declare which minimum version of perl it works with, but not the maximum one. Ditto with modules, which is more of a problem. APIs change, older features decided to be dropped as unsupportable or similar.
System Perls being upgraded is the source of problems with quick perl scripts, and the DarkPAN fear of not removing/deprecating perl and module features, but its not something we can influence. People need to upgrade their OS installs to keep up with security patches for all sorts of packages, including perl. So we could help reduce upgrading fear by providing min/max version support, and maybe some way of scanning the system to look for scripts that will not upgrade to newer module versions well.
Maybe we should have taught people to use versioned perl, for example #!/usr/bin/perl5.8.8 ?
The other way we could help Perl look better in general, is to have some way to announce/maintain a list of security bugs in Perl, and in the modules on CPAN. Or some sort of security audit for modules. This will also be a way to promote/sell Perl better. Perl coders like TIMTOWTDI, but what companies (read: managers making decisions) are looking for these days is assurance that using this "pile of random code contributed by anyone" that is CPAN will not help to create security holes in their systems. We're reluctant to single out modules for best practice use, but the reality is that there is a non-Core core set of modules that are reccommended for particular uses, so why don't we see to it that they're maintained, listed and audited?
It seems this is what the properl initiative is trying to do, but in a single-man un-coordinated attempt, which is possibly the wrong approach. On the other hand if one waits for a community decision, we could be here for a while.
It looks like EPO are attempting to do something like this, in an initiative called "Extended Core".
@public,perl
Last modified: 2009-04-08T22:19:56