Runtimes and Open Source? 43
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 (Score:4, Informative)
Re:Parrot (Score:2)
Re:Parrot (Score:1)
Re:Parrot (Score:5, Insightful)
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 (Score:4, Informative)
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... :(
Re:Parrot (Score:1)
Not only is it a strong possibility, it's assured. There will definitely be a Perl5 interpreter for Parrot as well, so all that old Perl5 code won't necessarily have to be ported or tossed out.
Re:Parrot (Score:3, Interesting)
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.
Java? (Score:2)
Re:Java? (Score:2)
Pretty much sums it up I think. From an OS perspective having Sun invovled (as much as they are) is a bad thing. Remember, in the end it's all about money to Sun - in a pinch you bet they'll piss of the community.
OTOH, one must ask if this is such a bad thing? Something like this was need an absolute authority. Absolute Authority goes against the grain of open source, the GPL at least.
What good would a common-runtime be if you needed 19 [slightly] different versions of it to run everything?
Re:Java? (Score:5, Insightful)
Parrot and Portable.NET (Score:3, Interesting)
open source runtimes... (Score:3, Informative)
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 (Score:4, Informative)
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.)
Is a Universal VM Possible? (Score:2)
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.
Re:A lot defacto in play (Score:1)
UNCOL [ic.ac.uk]!
Re:A lot defacto in play (Score:2)
I think the only viable solution is for OSS languages to develop interpreters for the main VMs... Python has the excellent Jython interpreter that lives completely in the JVM and is fully compatible with the CPython interpreter. Active State has Perl.NET which does the same thing for Perl on the CLI. It's a very good start (now, if only Python.NET was actually completed, I'd be happy...)
As always (Score:2, Funny)
(Emacs is a VM for running elisp code)
Competition... (Score:4, Interesting)
Well, someone else already meantioned it, Parrot [parrotcode.org] 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 :-)
Re:Competition... (Score:3, Interesting)
> not liking MS: it will be widespread, users won't have to install
> it since it already comes with your Windows.
Learn from the example of Java. The biggest problem with
deploying Java applications and applets is that there is no
good JVM available on client machines. The situation with
is no better -- in fact, it is worse. While (due to usoft's
illegal monopoly brigandage) 99% of all computers sold going
forward will run Windows XP and hence have a
computer sales are slow, and the number of Win95, Win98,
NT4 and W2K installations out there is probably growing just
as fast as XP (almost all illegal), and is much bigger to begin
with -- vast, even. As a result, you can't deploy an app or
a control over the net without incurring an enormous start-up
overhead to download the
It will be many, many years before
on Windows machines, and in the meantime, a *modern* JVM will
be shipping with Windows (and in Windows Update), so that
is in no better condition than the JVM.
Frankly, even the 800 lb. gorilla isn't going to be able to
push
for general deployment for a long, long time. Now for an
enterprise that has foolishly cast all of its eggs into the
Microsoft basket, and paid licenses or XP everywhere (or
administratively enforced the installation of
9x/NT/2000 desktops and laptops in the organization),
may be an appealling platform -- but I would much prefer to
avoid vendor lock-in and use a standard JVM, personally.
Especially when the servers run J2EE, so there is in-house
Java development expertise anyhow...
Re:Competition... (Score:2)
CLI unsuitable (Score:2)
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.
Re:CLI unsuitable (Score:1)
Re:CLI unsuitable (Score:2)
It wasn't an oversight, it was a deliberate choice. It makes the CLI unsuitable as a language-independent platform because it forces a choice that is the province of the language designer. It is just the grossest example of a detail that makes it impossible to export libraries written in in common languages in a natural way. Of course there are myriad more subtle gotchas with the same effect.
To understand how hard this sort of thing really is, look at what is done in Gcc so that it is possible to call and throw exceptions between C++ and Java. Imagine doing that for languages that are interestingly different from one another when you don't even know them. Then consider that you have to specify portable semantics of dozens of libraries that have to hide platform differences. It's no wonder this sort of thing doesn't really work.
It's very clever of MS to promote something that will appear to be portable, making people feel safe, but can never really be. They have got those Mono people completely flummoxed, and the Mono people are unwittingly helping to flummox everybody else. We can only hope that people's experience with Java will prepare them to examine the C#/Mono details carefully enough not to be burned again.
Case Sensitivity (Score:2)
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.
N.I.H.? (Score:2)
"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.
Re:N.I.H.? (Score:1)
I just don't agree (Score:1)
What am i missing? Why the VM and not just a good all ecompasing class lib?
"fat binaries" for how many architectures? (Score:4, Insightful)
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.
Re:"fat binaries" for how many architectures? (Score:1)
Re:"fat binaries" for how many architectures? (Score:1)
Also, don't rule out people ranting about slowness because they know a program is in Java and believe Java is slow. I once fell victim to this misperception until some performance numbers set me straight. ;)
Re:I just don't agree (Score:2, Interesting)
Less Interesting than They Seem (Score:2)
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.
More compilers (Score:3, Insightful)
caw caw... (Score:2)
I think this would cover a CLI / JVM kinda thing.
VMs (Score:2)
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.
GNU Lightnig? (Score:1)
http://www.gnu.org/software/lightning/ligh
GCC's RTL might be a candidate. (Score:3, Interesting)
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.
Inferno model is one to investigate (Score:2)
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 [vitanuova.com] than rely on my patchy description.
The source code is available if you pay. [& other stuff]