It's so sad. Parrot was conceived to be Perl 6's VM. Then the authors of Parrot decided to focus on making it more general purpose/language-independent, spent time writing incomplete implementations of various languages like Javascript on it, and ultimately didn't support any language well.

Parrot became so hostile towards its original purpose that Rakudo had to break from it.

Incidentally, I don't know why Perl folks don't implement Perl 6 on top of PyPy, which is a high quality dynamic language VM that already exists, and offers a JIT compiler to boot.

The main reason not to use PyPy is that Perl 6 is a gradually typed language, that is some type information is available at compile time. And that makes PyPy a less-than-ideal target platform.

(It actually seems that runtime environments that are optimized for statically typed languages, but have some support for dynamic stuff, suit Perl 6 better than dynamic runtimes. The CLR and JVM backends have the best run time performance so far, but they suffer from large startup times, which is something that the Perl community is very sensitive to).

Because (and that's a quote) "PyPy is unproven and experimental technology".

I'm probably killing the joke, but what makes this absolutely great is that this is a reason for Perl 6 not to use PyPy

Developing an experimental language is a huge effort. And that effort becomes much larger if the underlying runtime environment causes problems.

So either you need a proven, stable VM (JVM, .NET, mono, ...), or you need to have control over it, so that you can fix problems you encounter.

Basing it on an experimental VM that you don't have control over, and that might have slightly conflicting goals (dynamic vs. gradually typed, for example, different calling conventions for routines) is precisely the problem we had with parrot, and we don't want to replace the parrot problems with pypy problems, we can avoid it :-)

RPython is a framework for writing VMs.

You write an interpreter for your language in RPython (a statically typed language with syntax that is a subset of Python's) and the framework generates a VM with a JIT and GC and so on. You have full control over whatever happens in your interpreter, you can give the JIT hints and having types too early will not hinder the JIT.

You also keep calling it experimental, but PyPy is a production-ready Python VM, which is more than one can say about Parrot or even Perl6.

PyPy is production ready now, but that's actually a fairly recent development. I first heard about peel 6 in 2007, well before PyPy could have been predicted to work. Python barely had Psycho going for it. ParrotVM was the original form of PyPy, in some ways, and it just turned out to be too massively ambitious for a community that was already beginning to dwindle.

My point was that Perl6 and Parrot are still experimental.

Which PyPy problems did you have in mind?

parrot is definitely not dead. Some people left. It has some architectural problems (missing 6model and slow method calls) and had to survive some destruction done over the last years, but it had a good jit and has better threads than moar, which will bite moar sooner or later.

parrot threads are essentially lock-less and scale linearly, moar threads are traditional, they lock on every single hash, array or object access.

The parrot jit will come back soon. And I just fixed all internal compiler optimizations, so parrot -O2 is safe again.

On the other hand, the moar GC and calling convention is better than parrot, their new GC is a copying one, similar to the third vm targetting perl, p2 on potion. http://perl11.org/p2/

rurban is working hard these days to make Parrot fast again. Let's check again in a month to see how this went out :o)

It's... an ex-Parrot?

Sorry...