I'm actually somewhat surprised at how little Parrot is tied to Perl. Most of the active developers seem to be working on parrot for its merits as a VM. Perl6, for me at least, mostly provides evidence that this isn't just an exercise in intellectual masturbation, as Simon would say -- there will be at least one real language that targets it.
But even if it's tied to Perl less than one might expect, I don't disagree that it still smells strongly of Perl. Which isn't surprising, given its origins. The reason why it came into existence was Perl6; the early developers thus came from the Perl community, or at least the Perl-using community, and so implemented the supporting build system etc. with Perl; and the design of many things, particularly the more incidental things such as specific PMCs, was done from a Perl-centric perspective. Dan's designs tend to be more language-independent than others', probably because he has language independence as a stated goal while the rest of us rabble tend to only worry about getting specific concrete examples to work, and those examples are most often based on Perl. But let's remember again what the point of Parrot is, other than providing a way of running Perl6 code. To me, it all comes back to decoupling a VM from a language's compiler, which provides the following benefits: - The two to be worked on independently, allowing more freedom to improve each without worrying about backwards-compatibility or incompatible development philosophies. - It's easier to find experts in just one of the two components, rather than requiring an expert in both VMs and the target language. - Optimization is easier, since performance problems can be easily isolated in either the VM or the compiler. - Multiple languages can target the same VM, so more people are motivated to improve the VM (and thus hopefully improving all languages). But that's what we're talking about. These advantages exist equally for languages other than Perl, but all languages but Perl6 have one thing in common: they already have a perfectly functional runtime execution engine of some sort. Not only that, but they have an established group of experts for that runtime engine. And those are very good reasons not to switch. That means that Parrot has to offer some pretty convincing practical benefits, not just theoretical ones. And any perceived obstructions, real or otherwise, are going to make switching much less likely. If I imagine that I am a Python developer digging into Parrot for the first time, this is what I'd see: first, development is done on a list named perl6-internals. Hmm... I wonder how Perl-centric it is? That address is going to make it a lot harder to convince myself that Parrot isn't fundamentally bound to Perl. (The @perl.org doesn't bother me; if I have that much of a kneejerk reaction to the word Perl, I'm not going to touch Parrot until you drag me to it, kicking and screaming.) Second, the build system is written in Perl. Okay, that will be a nuisance, but I don't expect to work on that anyway. As long as it does its job, I'm happy, and if it doesn't then I'm not going to waste any time trying to fix it -- my time is better spent elsewhere, far away from Parrot. Third, the whole thing just seems too immature to be a realistic target yet. These PMC things sound fine, but my language requires a somewhat different set of operations and I can't find any working examples of arbitrary method invocation. It runs a tinderbox, but some machines have still been failing for a long time. The currently existing PMCs have strange gaps and tangles where a low-level one calls a higher-level one (and that higher-level one often has Perl in its name!). The documentation seems to be written for someone else who already understands more of Parrot than I do. Et cetera. In summary, I think we should try to remove the obstructions, partly because it's the right thing to do and partly in hopes that we'll be able to get more eyes and hands working on Parrot. But the main focus should be continue to make Parrot as robust, fast, and flexible a target as possible, because in the end that's the only thing that will persuade people to switch. And I'm guessing that the best way to that goal is to use Perl6 as the driver, at least until something else shows up, because that's the only way to derive realistic requirements for what needs to be accomplished.
