Andrew Stopford's Weblog

I agree with Scott opinion... managed code was absolutely better, not only for business applications. I believe a lot on Mono project.

So do I, Managed code is great..and Parrot does just that. For the moment its target languages are Perl and Python but its a runtime just like the CLR so there is no reason why languages like PHP and Ruby etc etc won't in time be managed code.

Why go for their own VM (Parrot)? Why not instead leverage the CLR or Java (assuming it's possible to create a decent Perl/Python/whatever compiler for Java bytecode)?

Scott's comments really have to do with developer productivity and little (if anything) to do with managed code. Simply porting perl or php to managed code does nothing for developer productivity. Increased developer productivity with existing managed languages is a result of:

1) the language features
2) the base class library features
3) availability of third party class libraries

Yes, there are a few things that a runtime can add to help productivity (like code access security). However, to a large extent the features of a runtime like the CLR aid language developers more than anyone else, because the runtime provides built in support for things like classes and garbage collection.

Perhaps language upgrades in Perl 6 or the next version of PHP will take it a bit in the right direction, but that still only solves 1/3 of the problem.

php with pear and Perl with cpan both have installers for base class library features, which solves the second third.

When it comes to productivity they both don't need to be compiled, which _is_ more productive then the Java or .NET way! Don't know how that's going to be with Parrot though.

Plus they are both open source and run on many platforms today.

When it comes to Mono, I simply don't see the sense of copying the functionality already existing.

C++ had a base class library too. Just having a BCL isn't enough. You need the kind of features that you find in something like the .NET framework's standard libraries. Perl or PHP on top of .NET or Java would solve 2 and 3, but cpan and pear don't even come close.

Glad we have a little debate going on here :) Jesse has a point that the BCL help increase productivity, stating that CPAN or PEAR don't help even the balance I will leave to someone with more know how on the subject. Porting PHP or perl to the CLR would bring about the other steps that Jesse mentions so is it not a mute point?

To adress the points raised by others, Perl and PHP on the CLR won't run well however. The dynamnic nature of the languages means that performance is poor (see the activestate.com experiments for more on that), changes to the CLR in .NET 2.0 and increased awareness of how to write a compiler for the CLR to allow for dynamnic languages (i.e. IronPython) will all help CLR adoption for such languages.

However Parrot is being designed up as a runtime for dynamic languages, and will I am sure run PHP, Perl, Python just as fast as the unmanaged versions. In time the range of dynamic languages from Perl to Ruby will have a managed code base.

Will they create a common code base such as the BCL, who knows, the Perl,Python and PHP communities are best placed to answer those questions. The point is that they are making the start down the managed code route and my point to scott is that its a little early to cast Perl, PHP or the like aside against managed code.