[ruby-talk:8319] Re: Ruby on .NET? A Perl Experience

Morten Hindsholm wrote:
 
# Matt Harrington <[e-mail]> writes:
# > On Fri, Dec 22, 2000 at 04:58:46AM +0900, Dave Thomas wrote:
# > > 
# > > So, stuff to think about. .NET compatibility may get to be a big 
deal, 
# > > and Ruby might get hurt without it. At the same time, it doesn't 
sound 
# > > like an ideal environment for a dynamic language.
# > 
# > 
# > I believe that's why Microsoft dropped VBScript as their preferred 
# > scripting language for .NET.  They favor JScript (ECMAScript).
# > 
# > I spend most of my time these days with .NET.  So far, so good. 

How so--i.e. are you using C#, JScript, or what?

# > I think 
# > ActiveState is working on Perl.NET and Python.NET. 

Yup, according to their web site.

# > the number of .NET 
# > languages is quite large now.  i last counted 19.

More important (for purposes of deciding whether and when Ruby should
be on this bandwagon) is (or will be) the number of their respective
users, relative to the number of users of the corresponding non-.Net
variants on (a) Win32 platforms and (b) other platforms.

Is there a useful *partial* level of .Net integration--i.e. Ruby/.Net 
(like Ruby/Win32) for (say) doing GUIs and getting at system services, 
versus a completely "Borg-ified" or ".Net-enslaved" Ruby.Net?

# Is anybody investigating how to run Ruby on the Java VM?
# 
# Being a fan of both the (dynamic) Ruby and the (more static) Java, I
# think it would make a lot of sense, and as we all know, the Java VM
# is cross-platform and all that.
# 
# The article mentioned in the original post links to a page
# (http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html) with
# descriptions of about 130 languages for the Java VM, including 4
# Eiffel and 3 Smalltalk implementations, so maybe it is possible...?

I haven't seen anyone mention actually working on this yet, although it's 
been discussed previously. 

Judging from randomly sampled discussions of JPython, this is a 
Certifiably Very Neat Thing (TM). 

But there are a number of sobering caveats. It seems to take a pretty high 
level of talent and ongoing work to do a good J<language> job (i.e. a 
well-performing, reliable, and industrial strength product versus a slow, 
buggy, but usable prototype) and to keep it viable for production use. 
There are some fairly rough edges, for instance, dealing with C 
extensions. You have added deployment issues. JVMs were only reasonably 
well debugged for instructions sequences produced by Java compilers, and 
there was little vendor interest in fixing JVMs for the benefit non-Java 
related products. On client-side GUI stuff, there were write-once, debug 
everywhere issues. 

However, I don't know the current status of such issues; I suspect some of 
these things have improved over the last couple of years. And depending on 
what you are doing, some of these may not matter much.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)