Perl 5, Perl 6, Moose, Rakudo and the Future of Perl

I made this comment today on my Google Reader feed with respect to Perl 5, and I thought it bore mentioning here since it's rather a longer topic than a blurb. The context was an announcement of a new project aimed at giving Perl 5 faster Meta-Object Protocol (MOP) support ala Ruby and Perl 6 (and to a somewhat lesser extent, Python, Lisp, and many others).

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)

Given a reasonable balance of those conflicting goals, a "Middle Perl" could be a powerful tool for transition to Perl 6 while also providing existing Perl programs a way to grow and adapt to modern needs. One immediately obvious counter-argument is that this will slow Perl 6 development. That seems reasonable, but on the one hand, Perl 6 has been in development for 10 years. Slowing it down isn't really possible. It is possible to steal its thunder and prevent its developer base from expanding at a critical time, so there's some valid concern there, but I think that can be mitigated by making Middle Perl and explicit stepping stone project that aims at ultimate adoption of Perl 6. On the other hand, there's the fact that developers are already working on this project, but only in module-space. They're implementing dozens of modules to extend Perl 5. If those efforts were re-directed to implementing a Middle Perl, then there would be no need for anyone currently working on Perl 6 or considering doing so to change course.

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.