Factually, Rakudo is not new -- there have been thirty-one development releases of it. But Rakudo Star is the first prototype of an end-user distribution tarball that includes the latest Rakudo, the Parrot virtual machine, existing documentation, build instructions and so on. I would say it is designed for Perl 6 experimenters, rather than Perl 6 implementors. It means that anyone interested in Perl 6 can now just do this:

$ tar xzf rakudo-star-2010.07.tar.gz
$ cd rakudo-star-2010.07/
$ more README
... satisfy library prereqs ...
$ perl Configure.pl --gen-parrot
$ make
$ make install
$ ./perl6 -e 'say "Hello World"'

For the Perl 6 project team -- or more broadly, anyone carrying the Perl 6 torch for the last ten years -- the release of Rakudo Star has huge symbolic importance. They're saying, in effect, "look at this cool project we've been working on! We want you to get as excited as we are about what Perl 6 will be able to do". And, you know what, if I were working on something for ten years, I'd be wanting to celebrate, too.

For those outside the project team, the significance of the release isn't so obvious. I can imagine a wide range of reactions:

• "Cool! I've been wanting to try some Perl 6 but didn't know where to start."
• "What's the big deal? I can't use it for anything real yet."
• "This sucks. It's too (big|slow|buggy|incomplete)."
• "Gee, thanks. Perl 6 gets the attention and Perl 5 gets ignored... again"
• "Perl 6?"

There is no way reactions to Rakudo Star can possibly live up to the hopes and dreams of those involved the project. I'm not surprised that some of the project members seem defensive in the face of criticism.

Leaving the emotional reactions aside, Rakudo Star still is a significant step forward for Perl 6, as it means inviting a less dedicated group of participants to test and react to the evolution of both the language and the implementation. Some of that will be negative, but some will be positive. More importantly, it will provide focus to the project going forward and shift the mentality -- gradually, one hopes -- from "get it absolutely right" to "get it done".

In the past, I've felt that the Perl 6 effort has been a distraction for Perl 5. On reflection, I've decided that the release of Rakudo Star is good for Perl 5 because it makes it easier for people to assess the relative status of both. Now, more than ever, it's clear that Perl 6 is not going to sweep Perl 5 away any time soon, but people who are interested in the comparison can watch both evolve and decide where they want to invest their time.

It's also pretty clear that Perl 6 is not going to make substantial inroads against Python, Ruby, PHP and other dynamic languages any time soon, either. If anyone was waiting for Perl 6 to rescue Perl, then they'll need to keep waiting.

However, Rakudo Star will help demonstrate common strengths of the current incarnation of both Perl 5 and Perl 6 language development.

• Timeboxed delivery -- both projects are now delivering regular, packaged development releases that users can unpack, install and explore to see how new features evolve and how it works with previously written code.
• Tests and a testing culture -- both Perl 5 and Perl 6 are backed by thousands of tests that help catch potential errors or behavior regressions
• CPAN -- Perl 5 already has it (and it's adding 1,000 distributions a month) and some of the early work by the Perl 6 community has been to start porting some of the more popular Perl 5 modules into Perl 6.
• Community -- there are dozens (or more) Perl conferences each year. These have often included talks on Perl 6 and this trend will likely continue. While Perl 5 and Perl 6 are different languages, they share not only a common heritage but a common culture as well

I suggest that people put the release of Rakudo Star in perspective. It is not a game-changer, but it is still a big step forward. Those who delivered it deserve kudos not brickbats, and I look forward to a next release that is even better.

Yesterday, Jim Keenan asked me a question about a Windows bug in some Perl code used in Parrot configuration.  My suggestion was to use a function from IPC::Cmd instead, since IPC::Cmd is core in Perl 5.10 and thus already well-tested across a wide range of platforms.

In his reply, he mentioned that Parrot configuration targets Perl 5.8 with only core modules (except things distributed with the Parrot source) and he added this as well:

And, in fact, the Parrot leadership has set the goal of getting every bit of Perl 5 code out of the Parrot distribution.  See, e.g., https://trac.parrot.org/parrot/ticket/619

I'm sure there's more to the issue, but as I don't follow Parrot discussions all that closely, my first reaction is that it seems unwise to me.¹

The advantage of Perl for configuration is that it's already portable -- so you can configure the same way on Windows as you would on Unix.  Take away Perl and then you're stuck with MSYS or cygwin, or other ports of Unix tools to Windows, none of which are as easy to use as, say, installing Strawberry Perl.

That Parrot ticket suggests using autoconf.  Really?!?  Google for "autoconf windows".  Here's a example of what you get: I hate autoconf.  Plus, you need Perl for autoconf anyway, so this approach layers a unix-y tool on top of Perl to build makefiles to build Parrot.  That's a lot of places for things to break across platforms.

I'd rather just have Perl.

In fact, I'll go further in my rant and point out that even Perl can't be automatically configured on Windows because it depends on shell scripts.  Instead, configurations are maintained and edited by hand in the Perl source, and anyone building on Windows has to hand edit them again  for any local customization.

I think that one of the reasons that Strawberry Perl has kept its momentum and frequent releases is that the build process got coded up into Perl::Dist, so that all the custom configuration needed to build a Windows Perl binary could be automated with Perl.

So, maybe as an "outsider" to the Parrot project my opinion doesn't count for much, but I think if they really want to be more portable and more automated, they should be looking to use more Perl, not less.

1. Unless the goal is to have Parrot completely bootstrap itself from existing Parrot binaries, which might actually be a decent thing.