Pain and Glory from the Trenches of the IT World

Earlier today I was reading an article about Parrot. Parrot is, as stated on the project’s Web site, “a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.”

So Parrot does sound like an interesting piece of technology. It’s understandable how a common runtime for scripting languages could prove beneficial. But will it ever be a platform suitable for serious, production usage? I have my doubts.

Parrot has been under active development for quite some time now. The initial 0.0.1 release was made on September 10, 2001. During 2007, we’ve seen a release every month or so. So a lot of effort has been put into Parrot over the past six years. It has surpassed one of the major stumbling blocks with many Open Source projects, in that it has managed to build at least some development momentum. Unfortunately for its supporters, Parrot has never really seemed to catch on. I think there are a number of reasons for this.

Stability is probably the first problem. I don’t mean “stability” in terms of the runtime crashing, or anything of that sort. I’m talking about “concept” stability. There has always seemed to be a relatively large amount of change between releases. While this is good, in that there are improvements being made and new ideas being implemented, this causes problems for users who want to build reliably upon Parrot. Individuals and businesses often do not, or cannot, invest the time and effort to track a continually-moving target like Parrot.

The language implementations for Parrot, while many in number, have been of limited use. Looking at the status messages of some of the most promising and practical language implementations shows why this might be the case. Such messages include:

• “Incomplete - but all examples and test cases are working.” (Amber for Parrot)
• “Most of the samples work.” (BASIC/compiler)
• “Has been broken for a long time.” (BASIC/interpreter)
• “Parser is pretty complete. Generates PIR for basic Ruby programs” (Cardinal, Ruby CVS Head 1.9 implementation)
• “Functioning, all samples working, lacks IO routines” (Cola)
• “Working for some simple forms. Due to some broken features, most of the bootstrapping code has been commented out.” (Common Lisp)
• “Functioning for handcrafted test cases. Loading frozen state is currently broken. Far from complete.” (Parrot m4)
• “This project has been abandoned. Any takers?” (Pint, an experimental PHP implementation)
• “Passes nearly 25% of tcl’s (lightly converted) test suite, using a Test::More like harness.” (Tcl)

So while there are many interesting language implementation projects for smaller or more obscure languages that have reached further stages of completion, the ones that were most likely to be of practical use seem to be lacking. Now, this is understandable. Maintaining a suitably complete Ruby, Python, Perl or Tcl implementation is not an easy task at all! And even if it were possible to come up to speed with the existing implementations, just staying current would be a major undertaking.

The third issue is that Parrot never really seemed to get a powerful backer. Java has Sun. .NET has Microsoft. Mono has Novell. Languages like Python, Perl and Ruby have large user communities, plus numerous business and academic supporters. While Parrot does have a unique community, as a whole I don’t know if it has the resources necessary to put together and maintain an effective, usable, multi-language runtime environment.

Having followed the project for some time, I have come to realize that it may never really amount to anything of practical use. Now, that’s not to say it’s useless. Putting it together has no doubt been an enjoyable task for many of its contributors. I imagine a small number of people have found a use for it. While it would be nice if it were to grow beyond that, it’s not something I expect to happen. It just doesn’t offer what most serious users need.

This entry was posted on Saturday, September 8th, 2007 at 1:34 am and is filed under Business, Common Lisp, Development, Java, JavaScript, Open Source, Perl, Python, Ruby, Software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.