From: MikkelFJ <mikkelj-anti-spam@...1.dknet.dk>
Date: 2001-07-13T23:17:01+09:00
Subject: [ruby-talk:17797] Re: .Net, JVM and languages.


"Mathieu Bouchard" <matju@sympatico.ca> wrote in message
news:6no37.7071$u76.149932@e420r-atl3.usenetserver.com...


> I think Ruby for JVM is much more important, because the list of
> JVM-enabled languages is about 10 times longer than the list of
> DotNet-enabled languages; and the JVM certainly hundreds of times more in
> use _now_ than DotNet (i prefer not trying to extrapolate).

I think it is important for Ruby to be running on .Net and JVM.
Ruby would have a bright future if it would support these.
These virtual machines are rapidly becoming the new operating systems. That
is - nobody really cares what is below as long as it works. JVM fails by not
supporting GUI sufficiently well, but succeeds on embedded and server side
applications. .Net seems to be addressing all these issues, although as
mentioned, only the future will tell where it succeeds.

Unfortunately, Ruby will most likely have to accept certain limitations in
order to run efficiently on these VM's - this is also what other languages
have been enduring. A direct port could make Ruby much slower than it needs
to be.

So either certain features are removed, or a compiler would recognize these,
issue a optional warning, and generate could in a less efficient way. It is
expensive to maintain two code generators.

Whatever the case, I believe we should be starting investigating what can
and what can't be efficiently implemented on these VM's.

There are issues with mutating classes and code execution before class
definition is complete (not necessarily a problem). There are differences in
the exception handling, in garbagecollection/finalize semantics. And of
course the thread issue.

Additional issues are compatibility with both the large base of Ruby source,
and with the extension libararies. It certainly is possible in both Java and
..Net, but how to do it, and what limitations there are, should be
investigated.

> Most likely (and as I said previously) it'll start off as an interpreter
> written in Java and/or C#.

Probably, but we really need a compiler. Making a bad Ruby compiler would
still benefit from optimizers applied to the bytecodestream.

> I maintain the following opinion: writing a good Ruby interpreter inside
> Ruby first, and Ruby in Java second, would be easier than just Ruby in
> Java; *and* results would be more incremental; *and* useful byproducts
> would come out of it.

What good would a Ruby in Ruby be? For understanding and clarification yes.
Perhaps also the compiler frontend, but the codegenerator needs access to
JVM/.Net API's for generating code. In Ruby we would have to port these
API's.

Wrt. compiler frontend: The compiler should plug well with development
environemnts, which is also not ideal in Ruby - unless it can be
bootstrapped to run on its own compilation running in the native enviroment.
A compiler should also be fast - Ruby is fast because it is interpreted, a
slow Ruby compiler would kill much joy. But again - bootstrapping Ruby could
make the result fast.

Mikkel