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?"
Parrot the VM for Perl6 is being developed w/ multiple languages in mind.
I don't see what the problem is with Java. I believe an open-source JVM and compiler for Linux are available.
This space intentionally left blank.
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.
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).
US Citizen living abroad? Register to vote!
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.
.pyc will work on any other Python 2.1 install. In addition, Jython will take Python code and convert it to JVM code.
.NET decisions, which would have hampered the execution speed of those languages. (Which I believe Microsoft wants to fix.)
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
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
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.)
(Emacs is a VM for running elisp code)
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 :-)
It's kind of silly, because they could have just mandated that languages that don't distinguish case should export lower-case identifiers, and then note that libraries that one wants callable from such languages should only export identifiers they can see.
Oh well, maybe next time somebody'll get it right.
Isn't this what proprietary companies are so often accused?
.NET platform and C# language, but it is in the industry's interests to diversify upon a common standard. There's no point in introducing an incompatible standard just because it didn't originate as Open Source. That there is an Open Source implimentaiton (which will be be essential to the new platform's vitality) makes the whole question prude.
"Not Invented Here! Re-invent the wheel plz k thnx."
Microsoft may be the source of the
The potential problems just come right back to software patents...
I think the biggest serious danger is the existance of a homogenous software platform. A homogenous software environment is deadly vulnerable to exploits, malicious and accidental. Already some bad security assumptions in the standard are known to the Mono project. I'm a bit concerned, but I think Mono is a Good Thing. The question requires you to disagree, and I don't.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.
I really feel that in this day and age we don't need a VM in the traditional sense. I think it would be much better if Java just compiled to native code and we had FAT binaries then people would just need libs like Java141.so and everything would work, and no one would bitch about java being slow.
What am i missing? Why the VM and not just a good all ecompasing class lib?
I think the problem is that there are so many issues involved. First, there is the desire to distribute machine independent code, then there are the runtime environments which is where things get really complex. Stripping away all the libraries of the environment, there are still a lot of issues relating to calling conventions (these are critical to maintaining the integrity of the user code "sandbox" (e.g. Java)), and data types (i.e. raw data structures of basic types vs. objects and strings, and the implications of this for memory management).
What may be possible is to settle on a small number of optional aspects of the VMs, but still have a single framework so that code from language systems that require different option sets can all be accomidated. The single unified VM that supports everything would probably be pretty big and complex, but at least it would be possible and practical, and the VM could manage the interfacing requirements to enable integration of sub-systems from radically different languages. Many choices in VM implemetation won't change the VM, but make a big difference in how well it runs. JIT technology, and other speed/space or even run/startup speed tradeoffs are part of it. Management interfaces is another area for variation that may also be visible in the environments (i.e. library APIs).
Seems possible, but it doesn't make sense from a single vendor with a single vision. I have always taken it to be axiomatic that no vendor should "own" a language. Writing code for a language system that can't be freely implemented by other vendors puts you and your organization at the mercy of a 3rd party. In most cases, this is folly bordoring on incompetence. I claim the same is true for VMs; don't give the vendor power to contol your future path/options.
If you need to support one-case environments, it's going to be hard to fully link these to more flexible environments. This goes for any mismatch in legal characters in external identifiers unless you have some complex standard for creating mappings or something.
The range of differences may be seen easily when you run ./configure after unpacking a typical
tarball. Given those differences, the differences
induced by the CPU architecture in the semantics
of (e.g.) C++ are not very significant, and are
easily coded around. The result is that our
familiar tarballs provide better portability
than the *VMs, because when you encounter a
problem, you can fix it, where with a bytecode
file you're just stuck.
The advantages of free software are not just political, they are bone-crushingly practical. The promises of *VMs tempt us to forget those advantages, but we keep getting reminded.
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.
I think this would cover a CLI / JVM kinda thing.
Only 'flamers' flame!
I an ECMA standard
.
I think you meant
I am ECMA standard
Congrats on standartization, by the way.
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.
Will I retire or break 10K?
I'm a Java developer. I'm really looking forward to Mono and Parrot. Hopefully they will provide the Open Source community an alternative to the de-facto C language, which seems to be universally applied to everything as low level as kernels, to as high level as GUI interfaces, other than Java which many developers seem allergic to, and to be fair does have its share of drawbacks, being proprietary apprently being foremost.
Not to mention that many of the tool languages of the Open Source world are interpreted and each have to maintain their own interpreter implementation.
It's 10 PM. Do you know if you're un-American?
There is a GNU vm out there, it just seems to need a little work thou.t ning.ht ml
http://www.gnu.org/software/lightning/ligh
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?
Lucent developed an experimental Distributed VM cum OS.
The idea is that the whole machine / OS is virtualised and thus standard across architectures rather than Java's seemingly halfway house. With users & groups and plenty of runtime features.
Better to take a look yourself than rely on my patchy description.
The source code is available if you pay. [& other stuff]
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter