Okay, folks, I’m gonna step out on a limb here.   I am not wishing to start a flame-war, and I beg your forbearance not to permit one to start.   I might be wrong here, but I think I’m right.   (And if not, it is just “IMHO,” and all of us here know how to deal with that.   So, here goes...)

In effect, Perl-6 becomes an entirely new language, with Perl-5 as its primary competition.   And, I believe that the Perl-6 team will be rather shocked to discover that their baby has no wings and will not fly.

A similar experience was shared by the various folks who tried at various times to create “ADD 1 TO COBOL GIVING COBOL.”   No matter what they did to try to “improve” the language, all of their “improvements” would have imposed gratuitous non-compatible changes upon tens of millions of lines of installed-and-working source code, with no significant return on investment.

Every now and then, someone comes along and says, “you really should re-implement all this stuff in (X) ... it will be so much better!”   And the seasoned executive holds up her hand upon hearing the word, “re-implement,” and says: “Stop right there.   No.”

The (X) could be “Perl-6,” or it could be Ruby or any one of a half-dozen other recent silver bullets, or it could be the next silver bullet yet to be invented, but the fallacy is the same.   The project would entail huge business risk, and probably would not provide business benefit, let alone a financial return.

Trivial example:   Go to your source-code directory and type “grep -rilw eval * | wc -l”.   If someone on the Perl-6 team decided that try was a sexier word to use than eval, and did not have the foresight to allow both words to be used ... then this is the number of source-code files that must be changed.   (And then changed back, if the Perl-6 rollout does not go exactly as planned.)   Meanwhile, where is the profit in it?   There isn’t one.   Huge risk, no profit.   So, what is the appropriate business decision? Stick with what works.   Stick with what is working now.   Let this “silver bullet” remain on the curiosity shelf with all the rest of its very many kin.

Furthermore, we have Moose.   Now, here is a very intriguing tool that introduces a strong object-oriented flavor to the Perl-5 language, without using an overt preprocessor, and without excluding the continued use of Perl-5 in the same system.   This is the kind of technology change that might get accepted by that same senior executive, because the risk of adoption is much lower and the implementation strategy can be incremental.   Even so, it still might not make the cut, although it is arguably “better.”