Perl 6? Yeah, right.

There are a lot of terms that a project does not wish to be associated with: "bloated", "slow", "insecure", and "archaic" come to mind. Perhaps one of the worst labels a project can receive, though, is "vaporware", a term reserved for projects that consist of nothing but hot air. If you had composed a histogram of the adjectives used by commentators to color Perl 6 whenever it made a news appearance, you might have worried that the developer community believed that the language was either dying, dead, or would be dead on arrival. Beyond the resulting disagreements over predictions of where this language is headed, there were also disagreements over whether the predicted doomsday scenarios would amount to a tragedy.

And who could blame many of these commentators? Perl 5 is now almost 12 years old. In the years that have passed, developers have been wooed by other languages such as PHP, Python, Ruby and Java. Perl 6 has not yet gone gold, despite the fact that it has been on the minds of Perl developers for years.

If Perl 6 is going to win back hearts and minds, it's going to need to be all that Perl 5 was, and more. It must still be the swiss-army chainsaw of UNIX programming. It must remain the glue that holds the Internet together, and it must keep the ability to mow down entire rainforests in 4 seconds. That's a very tall order, but Perl is famous for making hard things easy and impossible things doable.

Radically Different but Radically the Same

Larry Wall, the creator of Perl, intends for Perl 6 to be the community's rewrite of Perl. When the design phase of Perl 6 began, he asked the community for a series of RFCs. Each RFC proposed a new feature or change to the Perl language. When the dust settled, 361 RFCs had been submitted. Larry then began a process of responding to the RFCs in a series of Apocalypses (think "a Revealing"). Each Apocalypse addressed a series of RFCs, rating the presented problem, suggested solution, and finally casting a decision on whether the RFC as a whole was accepted. The Apocalypse documents formed the first official Perl 6 spec.

Perl programmers might worry that a rewrite would create a language incomparable to the one they grew up on; fortunately, that is not the case. In responding to RFC 28 (Perl should stay Perl), Larry agreed not to go raving mad but reminded that Perl is intentionally multi-paradigmatic. I am happy to report that Perl 6 isn't the work of a madman. It's much more of the things some language purists hate, but with half the calories, none of the hacks and a 16-cylinder turbocharged engine.

Here are some of the new concepts developers can look forward to using:

1. Coroutines are a general case of subroutines that allow you to return and re-enter at a later time. This model is especially useful for state machines.
2. Lazy evaluation defers work until it is needed, allowing the use of concepts such as virtual infinite lists.
3. Function currying essentially creates a new function based on an old function by predefining one of its arguments.
4. Junctions represent many values at once, allowing a test such as if ($variable ~~ any('str1','str2','str3')) { ... }
5. Hyperoperators, which apply an operation on an entire vector

In addition to introducing new features, the overhaul has corrected many shortcomings:

1. given is the new, built-in switch statement with the new ~~ smart-match operator for individual cases
2. Unicode processing is fully supported
3. Native object support makes classes, roles, methods, and attributes with strong encapsulation and fully object-oriented exception handling a fundamental property of the language rather than a run-time bolt-on.
4. Parameter passing in Perl 6 supports named and positional parameters and captures, providing all the flexibility of the Perl 5 calling convention, while supporting well-defined interfaces without the need to invoke third-party modules like Params::Validate.
5. Multi-method dispatch allows these new well-defined interfaces to be overloaded with different versions depending on the parameter signature
6. Threading, Garbage collection and XS, the system allowing Perl to link other languages, will all receive improvements as well.

But what is perhaps most interesting is what is happening to Perl 6's bread and butter: regular expressions and text handling. It will be possible to use Perl 5 regular expressions in Perl 6, but the system's new syntax features radical renovation. Regular expressions are now called Rules. This system provides named regular expressions with named captures, both of which can be represented and used in object form. Incremental regex matching can be combined with the system's new ability to write LL and LR Grammars directly in Perl 6 to create advanced parsers even more capable and easy to create than those made with the revolutionary lex and yacc tools of yesteryear. And for the fans of the C programming language, Perl 6 provides macro support, in the form of the ability to alter the Perl 6 grammar itself from within your Perl 6 code.

A Tall Order, Toppled

The promise of Perl 6 is not one that everyone expects will be kept. Surveying the extent of the Perl 6 blueprints, many armchair implementors might rate the requisite development effort as one in need of the infinite number of monkeys currently busy at their typewriters with the reproduction of the works of Shakespeare.

The good news is that the insurmountable task of developing Perl 6 is already well underway. Pugs is a project to implement Perl 6 using the functional programming language Haskell. Written by Audrey Tang, the Pugs compiler implements the Perl 6 language specification, giving programmers an opportunity to write real Perl 6 code today. This also allows the language designers to catch and fix any problems with the Perl 6 specification. The Pugs Subversion repository, currently tracking in excess of 12,000 revisions, is also home to a vast collection of example code and nearly 12,000 unit tests. Backends exist to run Perl 6 code natively, inside a JavaScript runtime, inside a Perl 5 runtime, or inside a Parrot runtime.

The Parrot runtime came to life as an April Fools joke in the form of a press release in 2001 that promised to merge desirable properties of Python and Perl. But whatever the original intention of the Parrot announcement may have been, Parrot is a very real software project whose most recent 0.4.6 release offers a common, free software virtual machine that aims not only to support the Perl 6 and Python languages, but also TCL, Ruby, JavaScript and others.

Pugs and Parrot are not complete projects. Neither claim to be the final, standalone implementation of Perl 6. But what we are looking at is clear. One of the most defining characteristics of Perl is that "There's More than One Way to Do It". It is a belief that choice is good and that flexibility is essential. Pugs and Parrot both represent powerful embraces of this ideal. Where Pugs demonstrates the possibility of running Perl 6 code in multiple programming language containers, Parrot demonstrates the possibility of running multiple programming languages in one container.

This flexibility means that programmers most comfortable using Python, Ruby or other languages capable of being compiled to Parrot bytecode can share functions, objects and modules. The famous Perl DBI and many other excellent CPAN modules can be shared amongst these other languages, rather than reproducing similar but incompatible systems time and time again.

Programmer portability is just as important as program portability. Parrot aims to run on as many of the 50 systems supported by Perl 5 as possible. This ensures bytecode produced by Parrot-enabled programming languages will achieve the kind of portability normally reserved for languages with a long and diverse history. Additionally, by providing a free software implementation of a true common language runtime, software projects like Apache that traditionally offered rich access to their internal APIs through projects like mod_perl can do so with an embedded Parrot runtime rather than a specific language interpreter.

It Starts Today

As mentioned, there is no official, production-ready Perl 6 implementation. But interested programmers need not wait for the future. Pugs provides the ability to run real Perl 6 code today. A number of CPAN modules provide Perl 6 technology inside the Perl 5 language. An experimental Perl 6 compiler written in Perl 5 is under development and currently passes about 10% of the Perl 6 test suite. Part of Perl 6 is already written in Perl 6. And an O'Reilly book, Perl 6 and Parrot Essentials, has already been on shelves for two years (during which time the language has, as you might expect, evolved considerably).

These projects won't stop concerned readers from asking "Would the real Perl 6 please stand up?" In truth, the concept of an "official" Perl 6 implementation misses the point. This is best explained by Larry Wall in Synopsis 1 under the "Project Plan" section:

Lastly, it is expected that Perl 6 will be self-hosting. The compiler for Perl 6 will be written in Perl 6 itself. This implementation effort is already underway in the Pugs v6 repository.