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?"

Comments

Parrot

[phnx90]

Parrot the VM for Perl6 is being developed w/ multiple languages in mind.

Re:Parrot

[Graelin]

Yeah, that's what I was thinking.

Parrot seems to achieve this goal to a degree. I don't know if the Parrot folk see it as an OS universal runtime and that may hinder it (in this capacity).

As you say, they're planning for multi-language support. I think they're trying to make it Python ready, that right there is two of the major OS languages.

I don't think Parrot will be adopted too quickly though. Look at Apache, 2.0 adoption has been slow due to lack of 3rd party modules. Now think about CPAN - same thing.

Re:Parrot

[babbage]

Yes, Python is a target language, as are PHP and Ruby. I understand that there have also been toy implementations of languages like Scheme & Forth on top of Parrot as well -- I don't know much about language design, but apparently those were good proof of concept languages early on. In addition, there is work underway on a mod_parrot Apache modules which would allow any Parrot capable language to run with Apache the way that mod_perl can today.

Parrot support seems likely to catch on because the plan is for Perl6 to run on top of it, and chances are very good that Perl6 will be adopted pretty widely in time. If other target languages have enough faith in Parrot to embrace it as well, then even better, but Perl alone should be strong enough to guarantee widespread distribution in due course. And everyone knows that all the current [by then "legacy"] code is going to have to be supported somehow, so backwards compatibility in one form or another is a very strong possibility -- which means that the problems Apache2 is having hopefully won't be so bad for Perl6. Hopefully.

The problem between now and then is that the three main Perl6 developers -- Larry Wall (language designer), Damian Conway (co-language designer & evangelist), and Dan Sugalski (low level implementation, including Parrot) -- are all out of work right now. They're all in the unfortunate position of being ridiculously over-qualified for most Perl hacker jobs, and finding an employer that would be willing to sponsor them to do Perl6 development right now is proving to be tricky. If anyone could give a hand to these guys, they and their families would appreciate it today, and the whole Perl community would appreciate it in the long term -- having them focusing on paying the bills kind of forces Perl6 to wait... :(

A lot defacto in play

[Jerf]

A lot of VMs already exist, even if you don't always see them. Anything that "compiles" to anything other then direct machine code is already running on some virtual machine.

I believe current Perl already does this, just completely internally. IIRC, OCaml does this, along with the option of compiling to a "true" executable. Python compiles to a Python virtual machine; the ".pyc" files are the virtual bytecode for that machine and are cross-platform; any Python 2.1 .pyc will work on any other Python 2.1 install. In addition, Jython will take Python code and convert it to JVM code.

VMs aren't that hard to build, as evidenced by the profusion of them. Standardizing on one has strong implications for the kind of language that can be run on top of it; witness the recent disappointment in the dynamic language community with some of the .NET decisions, which would have hampered the execution speed of those languages. (Which I believe Microsoft wants to fix.)

In fact, building a VM is often the best solution anyhow, as it give you a controllable layer for optimization, a controlled abstraction, and relatively easy cross-platform building. And for a skilled programmer already working with parsing and compiling some language, it's not that much extra effort to build overall.

VMs seem to me to be like programming languages; they aren't that hard to make. What's hard is making a really good one, and what's even harder is making one that everyone likes, which may not even be possible since I still here people bitching about RISC vs. CISC, despite the fact that the debate is nearly moot on modern processors. At the very least, true standardization into "One True Virtual Machine" is very, very premature; what I believe is that it's as bad an idea as trying to standardize into "One True Language", with almost a one-to-one correspondence for the reasons why they are a bad idea, and it should not happen ever.

(Which of course should not be confused with saying that any given VM should not standardize; that's obviously OK.)

Re:Java?

[Gerry Gleason]

One of the big problems cited in the past was that Sun would not certify OS JVMs, without a big fee. In most cases, this is impractical for OS projects that need to spend limited resources on development and infrastructure. I know some have suggested a certification "scholarship" idea, but I don't know if that has gone anywhere. I'm more willing to trust Sun and their long history of promoting open systems, if not open source, but others remain very skeptical.

Competition...

[DarkDust]

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 :-)

More compilers

[Mr. Shiny And New]

Rather than invent more VMs, why not just make a compiler that targets whatever platform you need? We'll always need compilers that target a real platform; we'll always need a compiler for each language that we want; a VM is just another platform... in the end the most popular language/platform combinations will have good compilers. Actually trusting a VM for anything non-trivial is bad. You can never be sure how a java program will run on another Java platform. I suspect that the same is/will-be true of C#/CLI/.Net. In the end, supporting a java program on two platforms is as much trouble as supporting a C program on two platforms.

"fat binaries" for how many architectures?

[yerricde]

I think it would be much better if Java just compiled to native code

There's a reason that intermediate representations such as JVM, MSIL, and Parrot exist. They act as a base from which the operating environment can recompile the code, optimized for a particular microarchitecture.

and we had FAT binaries

That may have worked for Mac OS 7, where a binary typically had two architectures' code (68020 and PowerPC) code, but for portability beyond the Mac, you need more architectures in the binary, to the point where it's bloated beyond belief. Do you really want to have to compile the same code for Alpha, ARM, Athlon 64, IA32, IA64, MIPS32, MIPS64, PowerPC, SPARC, and UltraSPARC architectures every time you release a milestone build to the public?

and no one would bitch about java being slow.

Java technology on the whole isn't slow. Implementations of the Swing GUI are slow. The Microsoft implementation of Windows.Forms GUI isn't nearly as slow as Swing, which is why the .NET framework seems to "feel faster" than Java technology.