Tels wrote:
Moin,
Hello Tels,
OTOH, who still runs pre-5.8.x code deserves what they get.
There are horrible bugs in older Perls, and I don't know why people
still
insist using insecure, buggy and feature-lacking code like 5.6. or even
gasp 5.004. Just think "Unicode support", "hash randomization", "memory
leaks".
You forget that there's more than one way to use Perl :-)
When Perl is used for sysadmin tasks, most of the features you listed
(and I could add "threads support", "new IO implementation", "signals
handling", "subroutines attributes") are of no to little use because
such Perl scripts are run for executing tasks that do not require
advanced Perl features like those just listed. Remember that on Unix
systems, Perl is like Bash, Sed and Awk, only more powerful (even if
it's by one or two orders). Do you replace your /bin/sh on your Solaris
with the latest Bash just because it has very new and cool features?
Usually you can't. Mainly because it could break things, and has little
to no added value.
Using these older Perls means you basically show the hard-working
Perl5-Porters that you don't care for their work in improving Perl.
But the Perl interpreter (which is what the P5Porters are working on)
and the Perl modules are mostly disconnected (*). Where would be the
interest to use an interpreted language if it were tied to a specific
version of the interpreter? Most Perl code out there don't require
recent features.
To continue with my previous analogy, there are also many people that
work hard on the Linux kernel, the GNU system, and all the different
parts that compose a GNU/Linux distribution, but when a server is in
production, you can't upgrade it at your wish.
(*) Yes, I know that the core Perl distribution includes many modules,
but ask any P5Porter and he'll answer you that the core is over-crowed
and that all core modules that can be made dual-life should be released
on the CPAN.
I know, now people will come out of the wood and say that they have
that
old system, and no, they can't upgrade Perl etc, never touch a running
system etc yadda yadda. But what the heck do you then try to upgrade
modules on said system when you didn't want to "touch the system"?
My current $work is to write a Perl program that must execute on about
1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I
can't upgrade Perl on these because they have different kernel / glibc
/ gcc versions. But that's not a problem because I don't need to
upgrade Perl or the modules on said systems, just to put the modules I
need in a directory and "use lib /that/directory". Of course I need to
use modules that work with 5.004, or patch them so they work with
5.004, but you could be surprised to see how little some of the patches
are. Can be as simple as removing "require 5.6" (as for File::Temp).
Most of the patches I've sent were less than 10 lines of differences.
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
