Slashdot Mirror
Runtimes and Open Source?
Caoch93 asks: "I recently read the Mono project's rationale and have found it compelling in the way it shows the Mono project as being the result of engineering concerns rather than concerns of siding with Microsoft. One thing that it has strongly bolstered in me is my belief that runtimes which interpret intermediary languages are going to play an increasingly important role in programming in the years to come, and it makes me wonder- should the open source community consider developing its own runtime (ala JVM or CLI) which would thus be totally open to the public? Currently, it seems like the options for a runtime are the JVM, which is still dominated by Sun with respect to its design future, and CLI, which is an ECMA standard but is critical to the Microsoft .NET platform. It would seem to me that having an open source runtime (and languages that compile to it) could be critical to moving with the times, and the freedom from proprietary influences would seem to be important to keeping such a system truly in the interest of its programmers. I don't know...is CLI already achieving this? I an ECMA standard enough, or is an ECMA standard really just codification of proprietary interests. If so, should the open source community consider its own itermediary language runtime...and what would be proper goals for such a project?"
While I can certainly understand the patent concerns, it is important to note that discussions have taken place between the DotGNU Portable.NET project and the people working on the next generation perl runtime. This provides a very good way out in case Microsoft goes after Mono and Portable.NET with patent claims.
Well, someone else already meantioned it, Parrot is Perl's way of doing a VM and looks really nice. So there already is a VM... beside other languages which use VMs already.
But I also think that too much competition in this field wouldn't be that good either. Don't get me wrong, competition is always good, but too much isn't since those competiting VMs targeted at the same market would stiffle its own distribution, IMHO, since it COULD happen that none gets a really broad distribution.
And a widespread VM is a good one, at least for the programmer, because he can assume the most widespread VM to be avaible to most to users, that is they already have it and don't need to install it first so that you're able to install your software. And requiring the user to install as few files as possible is a Good Thing(tm) :-)
And this is the reason why I think CLI will succeed, despite me not liking MS: it will be widespread, users won't have to install it since it already comes with your Windows. And others can use either MS's FreeBSD implementation or Mono. Would Parrot or another VM be included in Windows this one would succeed. It already was the reason for Javas success so far: the reason you already had it in you Netscape and former IE (AFAIK) made it very easy to use for end users. Had MS distributed an up-to-date JVM in XP, Java would have left no room for CLI, I guess.
Having others VM would be nice but with many people focussing on one VM the avaibility of good tools is better for that VM, thus enabling programmers to more easily write good programs.
On the other side there should always be an alternativ, just because there is no one true way of doing things and every application has a different need and thus you could choose the VM that fits your need more closely :-)
I think that Parrot needs more buzz about it. The real impact of Parrot would be that if Perl, Python, and Ruby all use it as their VM, then the triplication of effort in library building can be reduced. That is a powerful possibility!
Think about something like the Eclipse SWT. It uses native GUI calls and provides a platform independent java wrapper around them, and emphasizes a nice set of programming patterns. That could be naturally extended to any of Perl, Python, or Ruby. So build a gui kit directly in Parrot and presto -- you've got all three.
Additionally, work spent optimizing parrot benefits perl, python, and ruby simultaneously. Things like JIT and hotspot compilers can be developed for the benefit of all. I'd expect us to see a gcp counterpart to gcj as well.
You can profile and reoptimise using JIT, so a JIT VM should always be faster than a precompiled binary (after the application/library has been used a few times)
thank God the internet isn't a human right.
The Gnu Compiler Collection is a set of front ends that all convert the source code you feed them into an intermediate form called RTL (Register Transfer Language) which (as far as I've been able to work out) is a sort of pseudo-assembly language for an idealised CPU with an infinite number of registers and a whole bunch of other generalised rules.
. html), so you could use Trees, but I think they're only used for C and C++ so far.
This RTL is then put through transformations (generic optimisations & stuff) before being sent to a particular GCC back end that generates machine code for a specific CPU from the RTL.
So - why not save the RTL? It's an IL (Intermediate Language). If you added the ability of GCC back ends to run the code they generate directly, you've got an instant RTL VM.
Well, according to the docs, it's an internal form, doesn't contain all the program info, and is already partly optimised for specific platforms. (http://gcc.gnu.org/onlinedocs/gccint/Reading-RTL
But I'm sure there's got to be a mid-point somewhere in GCC that you could create a language->IL and VM/Processor pair out of.
K.
Why doesn't the gene pool have a life guard?