I'll believe that it will support "all dynamic programming languages" when they support Python.
Note that I used to believe in the project. I donated money to help them. Then I started to wonder what was going on there. Then for me the clincher was listening to Sam Ruby's presentation at OSCON a few years ago about his experience in trying to get Python running. From then on I've regarded Parrot as a fun project for those involved which I won't take seriously. Since then they've cleaned up development, they are making progress towards a far less ambitious Perl 6 than they set out to create, and I wish them well. But I personally doubt it will ever become widely used as a production platform, and I guarantee that it will never be widely viewed as the prime platform for running a wide variety of dynamic languages. If for no other reason than the fact that they don't have the people and resources to match what is being done on other platforms. (Have you paid attention to what Google has done for JavaScript execution?)
Just consider the facts. Python is a well defined target with multiple ports to different virtual machines. It is basically a perfect example of a realistically complex language in wide use. If you look at his background (see http://en.wikipedia.org/wiki/Sam_Ruby), Sam Ruby is pretty much the ideal person to work on a cross-language virtual machine. There has been literally no person that I've heard of in the Parrot project before or since who has as much relevant experience. And he failed.
The reasons why he failed are complex. But the biggest were all related to specific people problems (luckily mostly fixed since), and a design myopia that believes that Perl 6 subsumes all other dynamic languages, and therefore internal conventions that support Perl 6 efficiently will support everything else well (emphatically not true). Half those problems are gone. The people issues have improved, the design myopia has not.
Wake me up when they get serious about supporting Python. Until then any claims of "all dynamic languages" should come with huge disclaimers.
And I've responded elsewhere at http://use.perl.org/comments.pl?sid=44429&threshold=0.... For those who don't want to follow the link the short version is that I am unconvinced and still think the claim is false advertising.
> I am unconvinced and still think the claim is false advertising.
A port of Python 3 to Parrot is under active development (with the knowledge of PSF, which will probably hold the copyright on the project soon). It needs more developers, but what project doesn't?
Pynie is also a first-class project. Any changes it needs to run well it will get. (In truth, we test it and a few other high-level languages against Parrot trunk before we release our monthly versions.)
If you refuse to believe that Parrot developers are sufficiently serious about achieving our goals and that we work on them with every release, well, that's your prerogative. It would have been nice if you'd looked at our Languages page first, however.
You're criticizing me for not looking at your Languages page, when in fact that page has nothing to say that diminishes any point I've been making.
As I already pointed out to you, Python 3 is far from the most widely pointed out version of Python. The actual versions people are use in the wild are the 2.x line. Judging from http://pirate.tangentcode.com/, the unsuccessful attempt to port Python 2 has been abandoned for several years.
When it started it was called a first class project as well. There was theoretically lots of visible support. There is lots of prior art on how to successfully port it to a virtual machine. Some really good people tried to make it work. And the failure to port it resulted in literal pie in the face for the lead developer of Parrot.
I know that a number of things have improved about the project. Parrot is much healthier than it was. But I can't personally bother caring about it until after I see it succeeding with what should be the relatively easy stuff.
Volunteer time, interest, ability, and resources aren't fungible. Find us a willing cadre of developers to work on Pynie and I'll accept that writing and maintaining a full Python implementation is indeed "relatively easy".
If you can get Jim Hugunin involved then I'm sure you'll succeed. Actually you should reach out to him in any case, because he has more direct understanding of experience in making Python work with VMs than anyone else out there. Even if he isn't interested in putting out effort, I'm sure that any pointers he gives you will prove very helpful.
Most of the parrot languages in http://www.parrot.org/languages are sadly outdated or unmaintained. Many of them even not work in the current version of Parrot.
Our deprecation and support policy changed dramatically in the 1.0 release, from a monthly cycle to a six-month cycle. We changed to a three month cycle in 2.0 because of direct feedback from HLL developers that three months was way too long.
I don't know what you mean by "change the toolchain".
Note that I used to believe in the project. I donated money to help them. Then I started to wonder what was going on there. Then for me the clincher was listening to Sam Ruby's presentation at OSCON a few years ago about his experience in trying to get Python running. From then on I've regarded Parrot as a fun project for those involved which I won't take seriously. Since then they've cleaned up development, they are making progress towards a far less ambitious Perl 6 than they set out to create, and I wish them well. But I personally doubt it will ever become widely used as a production platform, and I guarantee that it will never be widely viewed as the prime platform for running a wide variety of dynamic languages. If for no other reason than the fact that they don't have the people and resources to match what is being done on other platforms. (Have you paid attention to what Google has done for JavaScript execution?)
Just consider the facts. Python is a well defined target with multiple ports to different virtual machines. It is basically a perfect example of a realistically complex language in wide use. If you look at his background (see http://en.wikipedia.org/wiki/Sam_Ruby), Sam Ruby is pretty much the ideal person to work on a cross-language virtual machine. There has been literally no person that I've heard of in the Parrot project before or since who has as much relevant experience. And he failed.
The reasons why he failed are complex. But the biggest were all related to specific people problems (luckily mostly fixed since), and a design myopia that believes that Perl 6 subsumes all other dynamic languages, and therefore internal conventions that support Perl 6 efficiently will support everything else well (emphatically not true). Half those problems are gone. The people issues have improved, the design myopia has not.
Wake me up when they get serious about supporting Python. Until then any claims of "all dynamic languages" should come with huge disclaimers.