Linked by Thom Holwerda on Thu 24th Sep 2009 13:35 UTC, submitted by Hiev
Thread beginning with comment 386016
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: It's the money train
by sorpigal on Fri 25th Sep 2009 14:07
in reply to "RE: It's the money train"
Can you tell me what is supposed to be so great about parrot? I don't see how it is better than the CLR or JVM.
People said the same thing about .net when it came out, "How is this any better than Java?"
The answer is different tradeoffs, and sometimes it's just nice to have a new perspective.
RE[2]: It's the money train
by Ed W. Cogburn on Sat 26th Sep 2009 04:23
in reply to "RE: It's the money train"
Can you tell me what is supposed to be so great about parrot? I don't see how it is better than the CLR or JVM.
You're correct. I suspect that the GP is just a Perl fan who wanted to plug his favorite language.
Nothing wrong with that, of course. Parrot is just another Virtual Machine, or "runtime system", like MS's CLR, Java's JVM, and all the other high level languages out there which require a VM system, like Python, Ruby, Lua, etc.
It may be a very good one, I don't know, but claiming as the GP did that its a "better CLR", is simply incorrect since its not compatible with the CLR, nor any other VM for that matter. Its a different system all together.
They also have powerful features for dynamic lookup.
CLR, yes, however JVM has some weaknesses in this regard which have made development of dynamic languages on it difficult (though obviously not impossible), but those should be fixed in Java 1.7.
By the way, if there is such a thing as the open source CLR, it is LLVM, not parrot.
LLVM is not a conventional "Virtual Machine", that "Low Level" part of the name is very important to keep in mind. Its a code-generation infrastructure that, theoretically, allows for compiling to native code, JIT'ing at run time, or running in a pure interpreter.
It is a "back-end" for a typical language compiler, and its real value, besides its modern, modular design and potential to allow code optimizations beyond what GCC can do, is that its intermediate representation (IR) is both hardware independent and relatively easy to use for a "front end".
Its IR is kind of like a pseudo assembly language, but one which has no hardware dependencies in its specification, so theoretically, a language front-end could spit out this "generic assembly" for LLVM to compile with no regard at all to hardware specific issues.
Now on the matter of LLVM versus other conventional VMs, in fact, LLVM has no "runtime system" at all. It is low level enough that one could build a conventional VM on top of it, but that hasn't been done yet, though there is a project called "VMKit" that is trying to do this.
However most of LLVM's use so far, and the focus of all its devs, is with its conventional compiling to native code. Its JIT'er and interpreter (which are at the core of all the conventional VMs listed above) always tend to lag behind (and at any particular time may simply be broken).
All of the effort of the LLVM devs right now seems to be focused on clang, their C compiler that uses LLVM as its back-end, which is "conventional" in that it only does the compile-to-native-code bit.
LLVM's potential is enormous, though its not quite there yet, e.g. not yet on par with GCC in terms of cross-platform optimized code-gen, but now that its development is controlled by Apple, its not clear, to me at least, what its future is going to be.






Member since:
2006-03-01
Can you tell me what is supposed to be so great about parrot? I don't see how it is better than the CLR or JVM. They also have powerful features for dynamic lookup.
By the way, if there is such a thing as the open source CLR, it is LLVM, not parrot.