That's untrue. This is just often perpetuated myth.

I've got lots and lots of perls: miniperl, perl 5.000, perl 5.6, perl 5.8, thos families of perl differ in way more significant ways then C implementations of different vendors.

And I've encountered some features, described in camel book(s), which just don't work in some (or most, or modern ) versions of perl, for example:

while ($sth=~/sth(sth)/g)
 {}
[download]

This forced me, (and for example Apache::ASP project) to instead use unefficient replacement:

$mycopyofstring=$sth;
while ($mycopyofstring=~s/sth(sth)//) {
}
[download]

The point here, is that important features of language appear and disappear at will, thus you've got to stay in-loop all the time, keeping and eye on changes, hoping that what you've learned won't be thrown out of the window next sumer

Same goes for your argument about vendors forcing stabilisation - debian folks loved perl and created most of their tools in perl. This backfired badly when some crucial parts of perl changed, thus forcing rewrite of large parts of those tools ( and quite complicated upgrade path - keep both perls on your system, for every package - download new package, remove old package, run it's postrm script with odl perl, run postinst of new package with new perl ).

Also please notice, that there is a very stronge movement to remove perl from base systems - OpenBSD, NetBSD, FreeBSD, many Linux distributions, they've already rewrote their perl scripts in sh/ksh, are talking about this or are actively rewriting their perl stuff.

If perl would provide this real basic and stable set of features, nobody would be moving away from it.

So what you want in fact is a really stable distribution of Perl? If what you needed works only in Perl 5.5.x, even that branch is still maintained, or rather, still mostly compiles on a lot of platforms. If you move within Perl5 releases, some breakage is to be expected in my opinion - that's why Perl 5.5.x still has a "maintenance branch", even though 5.5.4 had as its main change some fixes for gcc compatibility.

The Debian folks never got the spirit of Perl in my opinion, as they never released their modules and applications onto the CPAN, which makes integrating their modules with newer Perls quite difficult. But what you consider a "quite complicated upgrade path" I consider a triviality, and have made it into a rule: Never change your vendors perl. Upgrading or changing your vendors perl on your own will inevitably lead to a broken Perl installation and most likely to malfunctioning system tools too. Perl itself can live quite happily in different versions on the same machine and you should take advantage of that instead of fighting against it. Using Debians (or whatever other) package manager to manage Perl modules is, in my opinion, the wrong way to do things if Perl is central to your objectives. I know that others go the other way and maintain everything through their OS' package tool, but to them, Perl is merely one tool and not the central reason to run an OS.

The "very strong movement" is there because the Perl core is too big, and that's a good reason to want Perl out of an operating systems core. Perl 5.8.10 or 5.8.12 are supposed to get a much smaller core. Anybody doing non-trivial programming in any of the shells incurs a much higher development/bug hunting cost than (competently) using Perl. For a Linux distribution, the higher development cost may pay off in a smaller distribution size.

In the end, I think if you stick with Perl 5.5.x, you get the "real basic and stable" part of Perl on which you can rely. But, as the quote goes, biologists have this special word for "stable": dead - you can't have both, a live and evolving use of the language and its features and a stable set that never changes.

You'll notice that most highly evolved animals use internal skeleton which is mostly dead.

Stable core is good.

And I've encountered some features, described in camel book(s), which just don't work in some (or most, or modern ) versions of perl, for example:

001  while ($sth=~/sth(sth)/g)
002   {}


shortcut. This used to work in 5.000, stopped working in 5.6 because of broken optimisation. I reported the bug, but apparently this was considered a buglet, and left as is.

This forced me, (and for example Apache::ASP project) to instead use unefficient replacement:

001  $mycopyofstring=$sth;
002  while ($mycopyofstring=~s/sth(sth)/) {
003  }


I don't know what you're trying to show here, but the second example is a syntaxt error (Substitution replacement not terminated).

The point here, is that important features of language appear and disappear at will, thus you've got to stay in-loop all the time, keeping and eye on changes, hoping that what you've learned won't be thrown out of the window next sumer.

Important features? I think you mean experimental features.

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

I don't know about “experimental”, but was that behaviour ever documented? (Whatever it is, anyway, because I don't really understand what in particular the sample snippets are supposed to be doing or not doing, either.)

Makeshifts last the longest.