Squawks of the Parrot

The Genesis of the Parrot Project

Since this has come up, and we're seeing more exposure in more places lately, it seems worth taking some time to lay out the history and purpose of Parrot. This stuff is all bits and pieces that are kicking around the 'Net and the Parrot docs, so nothing here is new, modulo any failings of memory, but...

The History Part

It all started at The Perl Conference 4. This was in summer 2000, and I'm not sure if it was an OSCON by that point, but that's irrelevant. There was a morning meeting of the perl 5 porters, the group of folks responsible for maintaining and extending perl. It was sort of a pre-meeting meeting, as the 'official' (which is to say, scheduled with a meeting room handy) meeting was in the afternoon. Apparently¹ people, including Larry, were working on the standard brainstorming group session that results in walls covered in pages of notes and ideas. Useful, but nothing earth-shattering. Or earthenware shattering, for that matter.

About halfway through, Jon Orwant walked in, and threw what has been described as the most tightly controlled tantrum that anyone has ever seen. He also threw mugs at the door, one mug per word, just to add a bit of emphasis. The words were something like "Perl is dead unless you do something big". The last mug pitched at the door shattered as a bit of good timing, Jon left, and everyone there started thinking.

At the afternoon p5p meeting, it was announced that Perl 6 was starting, and we were going to to something fairly radical. Jobs (language designer, internals manager, PR hack, Corporate liason, project manager, QA, and documentation wrangler) were handed out to the folks there who either wanted them, or were best qualified of the folks who didn't not want to do them. Which is how I ended up with my job, but that's another story.

The public comment and design phase started then, and has been more or less continuing ever since. But at that point I started sketching out designs for the new engine. Nothing solid, since we didn't know what Larry had in mind for perl 6, but I did know what about perl 5's internals I hated, and the places it got in the way, so there was at least a starting point. The design progressed, albeit somewhat slowly, since I didn't want to start committing to a design for the internals until I had some idea of what functionality the language needed. Note that, at this point, the project had no name particularly, and was focussed entirely on perl 6.

The Perl community has a tradition of April Fools jokes. Some years they're quite good, others they're pretty understated and not impressive. (This year, FWIW, the joke was the hostile takeover of CPAN by the Matt's Script Archive folks, but that's another story) In 2001, Simon Cozens perpetrated a doozy. The gag was that Larry Wall and Guido van Rossum (the designer of Python) were burying the hatchet and designing a new language, Parrot, that would combine the best features of each language. Or the worst, if you were into that. There was a fake interview, some of the tech folks on both sides were in on it, and there was even an O'Reilly book announced, "Programming Parrot in a Nutshell". (Which is still in their online catalog) A good gag, very well executed, and if April 1st wasn't a weekend I think we would've had an amazing fit from a lot of folks. Ah, well.

Anyway, design on the perl 6 engine was still going on, but one thing that Simon and I both realized independently was that the engine we were designing really was suitable for pretty much any language in the same class as perl. (Dynamically typed, mostly OO, "scripting" language. Python, Ruby, and (I think) Tcl all fall in this category) Larry'd jammed an awful lot of functionality into perl 5, and all indications were that even more stuff was going into perl 6. It's not so much that we had to add things for Python or Ruby so much as perl was a proper superset of them. By the time TPC 5 rolled around in 2001 we were both convinced we could do it. We got together and talked at TPC 5, some other folks in other language communities (notably some of the python folks) were interested, and so not long after We announced our Master Plan. Of course we had to call it Parrot, because how could we not? Life was, in some ways, imitating satire, and that's the sort of thing you just have to go along with.

The first big public unveiling of Parrot was at the first Little Languages workshop that was being held at MIT. (And I'll note for the record that the only reason they'd heard of us was that I worked a few blocks away, and came up for some of the talks the Dynamic Languages group gave, and at one point Ben Stuhl and I spent the better part of the afternoon talking to Erik Kidd about efficient multimethod dispatch, as Ben and I missed the announcement that the talk was postponed, and showed up anyway. Which was really useful) Simon and I both gave presentations on aspects of the Parrot project, picked up a few things (like the fact that Ruby does continuations, which is why Parrot has them) and generally had a good time. Things have pretty much progressed from there.

The Up-front Part

Parrot started as the code to run perl 6. That's what got the project in motion, that's the community where we got our first developers from, and that's what's driving a lot of the development. Perl 6 also needs us--we're the engine. OTOH, Python, Ruby, PHP, Z-code, Befunge, Forth, BASIC, C#, and all the rest don't need us--they all have their own engines and system. If Parrot went away, Perl 6 would be screwed, while Python would just chuckle. (Only in the nicest possible way, I'm sure)

However...

Our mandate, such as it is, has gotten rather larger than it used to be. It is part of Parrot's mission, for various reasons, to run Python and Ruby code. While Guido and Matz don't have much control over what we do, it's not like Larry's got that much either. (Though he does have a bit more, but only because he's committed to using Parrot. If Matz or Guido made the same commitment they'd get the same say)

We also are specifically shooting to be a good general-purpose dynamic language engine. There's a lot of research and tinkering going on in the field, but folks are stuck either writing their own back end or targetting a decidedly non-dynamic back end, such as the JVM or GCC. That strikes us as silly, and since we're shooting for Python and Ruby anyway, well, it falls out nicely. This doesn't conflict with the need to support Perl 6, since it's a dynamic language.

What does this mean to you, the non-perl language designer?

Honestly, not much. While we're not going to make any decisions that penalize perl, neither will we make any decisions that penalize any other language in our class. We want to run Ruby and Python code well, and if someone wants to take a shot at something like PHP (well, OK, someone wants to help out Sterling Hughes, who's already shooting at it) great. Not only am I all for it, if there's stuff you want that we don't do, or do awkwardly, let us know and we'll do what we can to accommodate. Many of the dynamic features we already have or are working on (dynamically loading opcode libraries, pluggable bytecode loaders, and suchlike stuff) lends itself well to add-ons--worst case we don't do what you're looking for so you just go and write your own opcode library without uus and use Parrot as a glorified memory allocator and runloop. That's OK, we don't mind. :)

I'm really big on making things better, not worse, and more rather than less open. So while I won't compromise Perl's performance, I won't do it at the expense of anyone else's performance or ease of use. And when engineering tradeoffs arise, as they always will, well, we do the best we can, and who loses depends very much on circumstance. Might even be perl, depending on what the issue is... one never knows.

¹ I say apparently, as I wasn't there--I was teaching that morning.

Posted by Dan at April 18, 2003 06:13 PM | TrackBack (1)