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

[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... :(

open source runtimes...

[kevin lyda]

you mean like squeak? or perl's parrot?

since open source people don't worry about distributing source, scripting languages like perl, python, ruby and others fill this niche to some degree as well. binary vm's exist to a large degree to allow people to hide their source and still have portable apps.

plus i remember there being work long ago to have gcc's intermediate language done as a runtime. someone more knowledgable then me could mention that. and elisp precompiles (so does python).

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