I'll ignore the back-and-forth. Here's the bottom-line: Perl 5 is a dead-end platform. Not because of Perl 6, but because it's a deep legacy of parts that have out-grown their use. It's not extensible in ways that people want to use it today (e.g. for Moose and MOPs in general), and to bolt on those features is painful in the extreme, and guaranteed to be orders slower than it should be. I'm not saying Perl 6 is The Way. I'm saying that a re-design of Perl 5 is required to extend it into relevance with respect to today's programming environment. If that's called Perl 5.50 or if it's called Perl 6, it doesn't matter. Perl 5 is and should remain a powerful legacy language whose contributions to the state of the art were significant in their day but whose limitations are the right reason to use it only where required today.As you can see, I'm a fan of what Perl 5 has done. I think it brought some concepts "into the fold" of language design that were downright heretical at the time (grammar ambiguity can yield developer ease, for example). It also promoted regular expressions from library features and the domain of special-purpose languages such as sed or AWK to full-fledged peers in the design of a language.
However, Perl 5 is old and tired. To this day, it lacks such basic features as named subroutine parameters and it still has some deep confusion over types and naming that stem from its original idea that some types were so external that users should manipulate the namespace directly to access them. Why are these archaic features still in the language? Not because the Perl community lacks the skills to fix them, but because the language carries with it a heavy burden of legacy code. Breaking CPAN is such a taboo that maintainers have been forced into resignation over the frustration the community wells up when it or its evil twin, DarkPAN are threatened by the most trivial changes.
So, what are we to do? Moose and its ilk attempt to subvert the legacy code and inject new concepts by force. Sadly, that battle is one of attrition and diminishing returns. Ultimately speed and complexity are major factors in maintaining such a beast. Perl 6 (along with its currently hot implementation, Rakudo) is another path. Re-designed from the ground up, Perl rises from its own ashes with features freshly cast in modern terms. In many ways this is the right solution. Perl 6 is such a radical departure from the traditional design of popular languages that it is almost guaranteed to produce some of the same positive impact that Perl 5 brought us.
However, Perl 6 is fundamentally a new language. There's nothing wrong with implementing a new language that's aimed at the Perl community, but there's a middle ground that I think we need as well. Here are what I see as the design requirements of a new Perl that is still Perl:
- Provide basic functionality that Perl programmers want without cumbersome add-ons to implement them (named parameters, MOP, etc.)
- Maintain syntactic compatibility with Perl 5 as much as possible to ease transition
- Marginalize, deprecate or simply remove features which have hindered the task of implementing secondary implementations of Perl 5 (e.g. on Parrot)
Many times I've heard Perl 6 compared to Python 3. I always point out that this is an unfair comparison because Perl 6 is a radical re-design of the language which requires blazing a new trail through the entire topic of language design and the integration of disparate programming paradigms. What I've suggested here, however, should absolutely be compared to Python 3. A re-evaluation of some core concepts; a re-write of the code; but fundamentally the same language.