Heroes and Parrots
by Schuyler Erle
Parrot internals mastermind Dan Sugalski fielded an interesting question at YAPC in St. Louis, during his pair of talks Wednesday morning on the development of Perl 6's virtual machine.
(A virtual machine, Dan explained earlier in the talk, is a software layer that abstracts the details of computer hardware away from the developer, allowing them to write code for an idealized "virtual" machine that can then be run anywhere. Most dynamically-typed languages, like Perl 5, Python, Ruby, et al., underlyingly implement some form of VM, as do certain statically-typed languages, such as Java or C#.)
"How," Dan was asked, "does the Perl 6 VM compare to Perl 5's?"
Compare in what way? It's smaller, but then it's not done. It's cleaner, but then it hasn't been loose in the world with hordes of people using it and breaking it for eight years. There were a lot of things we wanted to do in Perl 6 that were difficult to do in Perl 5. Threads, for example, or Unicode. You can't add threads in after the project is done. Assumptions that are perfectly safe in a single-threaded case are things you curse four years later in a multi-threaded case.... Other stuff, co-routines. Perl 5 is a larger piece of software, it's seven or eight years old, it's lots of warts... er, endearing qualities. It was easier to just start fresh -- there's been another decade's worth of CS research to build one. It was time to start fresh. So we did.
Such an effort seems almost immediately daunting in its scope, but the Parrot team have made remarkable progress, and demonstrate even greater promise. The code base, pumpking-ed first by Simon Cozens, and more recently by Jeff Goff, has by design the capability to support a wide variety of opcode tables -- tables of functions that describe how a programming language is expected to perform basic operations, like arithmetic, string processing, I/O, etc. Already, a variety of languages are supported at least in part, including BASIC, Scheme, Jako (a C-alike), Cola (a Java-wannabe), and Parrot's own low-level assembler language. Support for a whole slew of others is planned or already in progress, including Java, C#, Python, Ruby, Perl 5, Z Machine (yes, the RPG-building language), and, you guessed it, Perl 6.
But the really exciting thing about this is that Parrot's notion of the "current" opcode table is lexically scoped, and can be loaded or reloaded on demand. Dan noted that this would allow piecemeal upgrading of Parrot components, but the part I find really fascinating is that it would permit the use of multiple supported languages in a single script. Imagine writing a program that defines one method in Java, another a Ruby, a third in Python, and then calls all three methods from Perl, all without ever leaving the Parrot interpreter. Look out, Inline.pm -- here comes Parrot. The very possibilities boggle the mind.
There's still an enormously long road to hoe, though. As the design of Perl 6 coalesces, the development of Parrot needs to proceed apace. Simon Cozens, speaking after Dan, related some of the difficulties of leading Parrot development. "You are trying to create a computer program," he said, "A computer program is constructed out of code. It is not constructured out of email messages.... Code is better than talk. Firm decisions are better than talk. Even if they're wrong."
Well, now is the time for all good hackers... In his keynote earlier in the day, Larry noted that Perl has saved people and companies literally billions and billions of dollars over the years. He also pointed out that "a real hero has to be more interested in serving than in being served, in loving than being loved." We need hackers who have benefitted from Perl 5 to step forward and give back to their community by volunteering on the Parrot project. And, perhaps even more so, we need companies who have benefitted from Perl -- free Perl, Open Source Perl -- to give back in the form of donations to the Perl Foundation, to support the people who are blazing new ground into the future of Perl itself.