Lambda the Ultimate

One of the big problem I see with Parrot is that the compiler is written in C, and not in Parrot or other highlevel language. That might slow down compiler development significantly and increase the number of possible bugs, compared to writing a compiler in OCaml/Haskell for example.

You wouldn't want to write the Parrot compiler in Parrot. It's not a high level language. It's assembly for a VM. That it's written in C shouldn't be so bad given that limited scope.

I would be more worried about the Perl 6 compiler being written in C, but it's not. It's written in Haskell.

As far as I remember, there is now two languages in Parrot. One very low level (PASM) and one intermediate level (PIR) that does a lot more things and require a lot more C code.

There is a project to implement Tcl on Parrot, ParTcl. I'm not sure what the current status of it is, but this journal seems to be the most up-to-date source of information. I remember there was initially some doubt about how well Parrot would support a language like Tcl, so it's interesting to see how this project is coming along.

Parrot is starting to become the Duke Nukem Forever of the VM world and a big Perl 6 uptake is unknown at this time. And then of course, the author seemed to be talking about the desktop and not the server world.

The vast majority of desktops will have a CLR eventually because Vista will have it, which should fuel the uptake on XP and friends.

I was over at theserverside.com and reading one of the discussion that the editors over there put out every once in a while to fan the flames, Java Dead like COBOL and the discussion turned to other languages running on the JVM. One guy that apparently works on GNU classpath and an open source JVM claimed that because of backward compatibility concerns, Sun won't do enough to change the VM to better accomodate other languages (especially dynamic ones).

Those that have much more insight on the technical innards of the JVM vs the CLR might want to comment on the pros and cons of their current offerings. It seems that the CLR would have the upper hand, but I'm not sure. And from my observations, it doesn't appear that Java will ever regain (if it ever had) some ubiquitous presence on the client.

On the client it appears to be the javascript interpreter, the CLR (at least for windows), and Flash.

Here's my take on VM comparisons, comments appreciated :

• JVM has very good implementations, but is best suited to run Java or languages having a Java type system. You can off course run other languages on it but that require a lot of difficult work to fit your type system into the Java one and the resulting classes might be strangely-formed. This can cause expected results when using reflection for example. Having and hidden runtime complexity is never a very good thing.
• the CLR is powerful, but is quite difficult to target. There is a lot of things inside it so you can write very optimized compilers but it require a lot of work. It's also highly tied to C# but is less restrictive than the JVM. In the end, if it was OS from the begginning and not a MS product, it would maybe have a chance.
• Parrot is old, big, and not so much quick. I guess it suffer from its Perl ties and time since the project started.
• Flash is only for the Web. There is no OS implementation yet (FSF people are working on it, see the Gnash project). Also, it's not been designed for several languages (although you can target it) and the VM design produce very slow bytecode.
• My implementation of what I think would be a very good VM is Neko (sorry for the urls posts, I'm eager to share thoughs about my work :). It's lightweight, reflective, flexible, dynamicly typed and still very quick VM. There's a very well defined intermediate language for targeting it very easily.
• There's also LUA but the language design reduce the optimizations possibilites.

It seems that it highly depend on how you do it, a lot of optimisations aren't implemented right now and they could make a great deal of a difference. Look for example at this subject .
Parrot isn't in a usable state now and I wonder if it will ever be, but it's an interesting dream... :)

--
Jedaï

not so much quick

maybe you posted this before you read the reply from the parrot people over on perl.perl6.internals - http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/1f6abd7132f12ab9 - but i'm kinda surprised you didn't update your comments above when you found out that with the correct compiler flag it runs about a factor of 100 faster than your tests...

Just need some free time to run the tests again. The comments on my blog have been approved and link to Leo answer.

I understand you have to plug your own VM:-), but you completely missed mentioning Mono.
Mono is OS from the beginning (the runtime/JIT is LGPL, the C# compiler GPL, the base libraries X11).
It is as powerful as the MS CLR, only it runs on many more architectures (x86, ppc, sparc, amd64, ia64, arm, s390, s390x at last count) and operating systems.
Targeting it is not difficult at all. It's actually much easier than, say, Parrot, since you can write the support libraries for a language in high-level languages like C#.
It is also quite clear you haven't investigated much the internals or you'd find that the VM is not tied to C# at all and infact has many features that C# can't access.
You may want to read IronPython's papers about some of the topics of targeting IL code.
Mono has also a large community providing support and is included in basically all the Linux distributions.