Advocacy: Ruby on/with .net

T

Thomas Sondergaard

I'd like a minute or two of your time as I try to sell you the idea of ruby
on/with .net :)

== Ruby the language rocks, ruby the platform not as much ==
I love ruby the _language_, but there are often annoying obstructions when
you want to develop an application on ruby the _platform_, like missing or
immature class libraries and poor threading support (IMHO).

== .net is the future ==
It is my firm belief that .net as a development platform is very powerful. It
has been my main development platform for more than a year and a half and
considering how young it is things just work amazingly well and performance
doesn't suck, like it at least initially did with Java. Technically the .net
framework and runtime are excellent and with Microsoft pushing it as hard as
possible it will end up on most Windows computers sooner rather than later.
The mono project is doing an excellent job of making sure that the .net
platform will also be available on other OSes than Microsofts. I am not a
Microsoft fanatic, but after having used .net for a long time I must admit it
just works very well. I don't think it is worth sticking our heads in the
sand, just because we may not approve of Microsofts business methods,
especially as the .net runtime and base framework have been made open
standards.

== Ruby on/with .net ==
Ruby is not a scripting language front-runner, but as a language, not a
development platform, it leaves the front runners in the dust. By relying on
a common and very popular platform we can do away with most of the
disadvantages of ruby and keep the advantages.

== Projects to take ruby to .net ==
After having perused the documentation for the .net CLR runtime and the CLS
and read a white paper on the lessons learned trying to make Python run on
the .net CLR runtime, it is clear to me that the .net runtime is not well-
suited for dynamic languages, such as Python, Perl and indeed ruby. However,
smallscript inc (http://www.smallscript.org) are working on exactly that, and
will soon be releasing a version of smallscript, a smalltalk variant, that is
running on the .net CLR. I think it would be worthwhile to pursue two
projects, one with the objective to allow .net class libraries to be used
from ruby using a dual-runtime approace and another approach that attempts to
run ruby on the .net CLR runtime

=== rubydotnet - dual runtime approach ===
This project will aim to allow any CLS compliant .net assembly to be used
from ruby. This would make all .net class libraries including the entire .net
framework to be used from ruby, without having to implement ruby wrapper
modules.

=== r# - ruby on the .net runtime ===
r# is to ruby, what S# is to smalltalk (http://www.smallscript.org)
This much more ambitious project would aim to run ruby on top of the .net
CLR. I, personally, would be willing to make some adaptions to the ruby
language to facilitate the .net platform integration, and do away with much
of the core ruby platform. Making ruby, or rather r#, fully CLS compliant has
many advantages in terms of distribution and in terms of using ruby/r# with
asp.net and running ruby applets inside browsers etc.

== Status ==
I have just today submitted a project registration with sourceforge.net for
rubydotnet. rubydotnet has a much smaller scope than r# and will allow the
ruby community to see the benefits of ruby/.net interop. Hopefully after that
support can be rallied for the much more ambitious r# project.

Thank you for your time

- Thomas Sondergaard
 
T

Thomas

Thomas, are you actually going to be programming this project?

Yes, that is my intention. I'm currently probing the community to see
what interest there is for the project. I'm currently travelling
around in southeast asia, but in about a month I'll settle down
somewhere in southern Thailand and start coding.

Would you be interested in contributing, or are you otherwise
interested?

Cheers

Thomas
 
M

Matthew Diephouse

Thomas said:
I'd like a minute or two of your time as I try to sell you the idea of ruby
on/with .net :)

== Ruby the language rocks, ruby the platform not as much ==
I love ruby the _language_, but there are often annoying obstructions when
you want to develop an application on ruby the _platform_, like missing or
immature class libraries and poor threading support (IMHO).

== .net is the future ==
It is my firm belief that .net as a development platform is very powerful. It
has been my main development platform for more than a year and a half and
considering how young it is things just work amazingly well and performance
doesn't suck, like it at least initially did with Java. Technically the .net
framework and runtime are excellent and with Microsoft pushing it as hard as
possible it will end up on most Windows computers sooner rather than later.
The mono project is doing an excellent job of making sure that the .net
platform will also be available on other OSes than Microsofts. I am not a
Microsoft fanatic, but after having used .net for a long time I must admit it
just works very well. I don't think it is worth sticking our heads in the
sand, just because we may not approve of Microsofts business methods,
especially as the .net runtime and base framework have been made open
standards.

== Ruby on/with .net ==
Ruby is not a scripting language front-runner, but as a language, not a
development platform, it leaves the front runners in the dust. By relying on
a common and very popular platform we can do away with most of the
disadvantages of ruby and keep the advantages.

== Projects to take ruby to .net ==
After having perused the documentation for the .net CLR runtime and the CLS
and read a white paper on the lessons learned trying to make Python run on
the .net CLR runtime, it is clear to me that the .net runtime is not well-
suited for dynamic languages, such as Python, Perl and indeed ruby. However,
smallscript inc (http://www.smallscript.org) are working on exactly that, and
will soon be releasing a version of smallscript, a smalltalk variant, that is
running on the .net CLR. I think it would be worthwhile to pursue two
projects, one with the objective to allow .net class libraries to be used
from ruby using a dual-runtime approace and another approach that attempts to
run ruby on the .net CLR runtime

=== rubydotnet - dual runtime approach ===
This project will aim to allow any CLS compliant .net assembly to be used
from ruby. This would make all .net class libraries including the entire .net
framework to be used from ruby, without having to implement ruby wrapper
modules.

=== r# - ruby on the .net runtime ===
r# is to ruby, what S# is to smalltalk (http://www.smallscript.org)
This much more ambitious project would aim to run ruby on top of the .net
CLR. I, personally, would be willing to make some adaptions to the ruby
language to facilitate the .net platform integration, and do away with much
of the core ruby platform. Making ruby, or rather r#, fully CLS compliant has
many advantages in terms of distribution and in terms of using ruby/r# with
asp.net and running ruby applets inside browsers etc.

== Status ==
I have just today submitted a project registration with sourceforge.net for
rubydotnet. rubydotnet has a much smaller scope than r# and will allow the
ruby community to see the benefits of ruby/.net interop. Hopefully after that
support can be rallied for the much more ambitious r# project.

Thank you for your time

- Thomas Sondergaard

You may be better off contributing to the parrot project
(http://www.parrotcode.org) -- the perl 6 interpreter. It is like, like
..NET and Java, a virtual machine. However, it is being built for dynamic
languages. Parrot will eventually run Ruby (along with Python, PHP,
Scheme, and others) anyway. It appears you already now the troubles with
..NET and dynamic languages. But if you want to read more (why they're
developing parrot), you can check out these two blog entries, by Dan
Sugalski, the lead developer:

http://www.sidhe.org/~dan/blog/archives/000151.html
http://www.sidhe.org/~dan/blog/archives/000152.html

matt
 
L

Lothar Scholz

Maybe i'm completely uninformed but what is the real benefit of .NET.
You can use the Visual Studio .NET IDE (never worked with it, but
Visual Studio 6 is a pain to use).
And it is easier to get alien like looking library wrappers that still
need to be rubyized by hand. I don't see a real advantage here in
contrast to use (and extend) the SWIG tool.

And most libraries are only for windows. The mono project has a complete other
goal then Microsoft when it comes to libraries. Read the announcements carefully
and you will find that they use it to interact other languages more
easy, but they seems not to be interested in realeasing a large and
complete set of libraries. Simply because they don't have to money
that SUN has and can't hire 100 programmers in Bangalore.

So i would recommend to forget about .NET and put our focus directly to the
libraries and the core language implementation. There is enough work
to do.

By the way, if you want to change the threading support you completely break
the language. Can you tell me if .NET supports fibers ?
 
G

Gawnsoft

How do you mix the lack of thread safety of Ruby's interpreter with .NET
real threads? I'm facing that problem with rjni (Java binding).


I hope your grandchildren won't use Windows anymore.

Given that over 90% of the installed desktop base uses Windows, and
that it's been successfully (in terms of market take-up) targetted at
handheld devices and servers, this may be a forlorn hope.

The very first IBM-compatibles almost all used Microsoft OS.

The current IBM compatibles almost all use Microsoft OS.

This creates an enormous network effect that tends to lock in the
Microsoft OS - as long as they maintain adequate
backwards-compatibility for apps.

And even if other folk take over the role of providing a platform for
apps which were built for Microsoft OS, the biggest platform available
will still be platforms that can run apps which were built for
Microsoft OS.

We may bemoan the fact, but facilities which allow Ruby apps to run
and run well on the Microsoft OS platform(s) are good for the
penetration of Ruby apps into the world.



Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
 
P

Patrick Bennett

The other advantage is that a native CLR implementation of Ruby would
let you use *any* .Net code/component (and vice-versa) whether it's
written in C#, VB.Net, Eiffel.Net, etc. etc.
It might be painful, but I think a .Net implementation would be phenomenal.
 
J

Josef 'Jupp' Schugt

Saluton!

* Mauricio Fernández; 2003-07-21, 12:07 UTC:
I hope your grandchildren won't use Windows anymore.

Even though his name suggests that: How can you be sure that Benjamin
doesn't already *have* grandchildren? Life is a permanent violation
of the principle of least surprise.

Gis,

Josef 'Jupp' Schugt
 
J

Josef 'Jupp' Schugt

Saluton!

* Gawnsoft; 2003-07-21, 17:46 UTC:
Given that over 90% of the installed desktop base uses Windows, and
that it's been successfully (in terms of market take-up) targetted at
handheld devices and servers, this may be a forlorn hope.

I don't try to sketch an image of what computing will be in 30 years
because that is doomed to fail. Only one aspects seem to be
relatively sure: Whatever will be the operating system in 30 years or
so will almost certainly be no 2D system. Silicon Graphics is working
on a 3D user interface and so is Microsoft. Even if Microsoft happens
to keep a 90% share of the market it is *very* unlikely that their OS
will be called 'Windows'.

Maybe we are going to use the successor of Windows, maybe we are
running Linux, or maybe we are struggling with the Chinese OS that we
have to use. Who knows?

It is also not too likely that we will be using Ruby - remember how
much changes in programming language design took place since the
early 1970's.

Gis,

Josef 'Jupp' Schugt
 
A

Aredridel

I think some still use Ruby, as some of us still code COBOL or FORTRAN
(or Lisp) now. Ruby in 2038 will be different from Ruby in 2003 though.
It will no longer use 32bit time_t.

Matz, you make me laugh in the best ways.
 
D

daz

Benjamin Peterson said:
[...] Ahh, to think, my windows GUI programs could be
written in ruby! A dream that I doubt will become real
in my lifetime ... but perhaps, my grandchildren ...


That's your choice.

Anyone who has installed the PragProg package, will
have FXRuby and Tcl/Tk for cross-platform use and the
vruby/swin combo which is very powerful for native use.

http://www.threeweb.ad.jp/~nyasu/vruby/vrproject-e.html

Download some samples. They're not designed to impress,
they're to illustrate usage where English documentation
is difficult to offer.

At least, when you've written your GUI app, you'll
have impressed yourself.
 
B

Benjamin Peterson

Mauricio Fernández said:
How do you mix the lack of thread safety of Ruby's interpreter with .NET
real threads? I'm facing that problem with rjni (Java binding).

It is just barely possible (but very unusual and perverse) to use
fibers with .NET, as mentioned here:

http://blogs.gotdotnet.com/cbrumme/PermaLink.aspx/9fd9222c-ee65-424d-867e-8e4e52ea394b

---

However, I wasn't envisioning using the current Ruby interpreter,
which is problematic in many ways. To enjoy the features we have been
fantasizing about in this thread, I think we would need one of three
major levels of functionality, listed easiest first:

Level 1
Feature: Use .NET libraries
Minimum Requirement: A module in Ruby to load and call .NET
assemblies. It doesn't seem to be hard to write a C program to load
..NET assembly (and the runtime) and run a method (this is what
assemblies in the form of .exes do all the time). Presumably this C
code could be made into a ruby module.

Level 2
Feature: Take advantage of .NET infrastructure (threads, unicode,
etc)
Minimum Requirement: A ruby interpreter (or bytecode
compiler/interpreter) written in .NET, that reads ruby instructions
and executes .NET code in response. There is one lying around 3/4
built already.

Level 3
Feature: Fully integrate ruby modules with those in other .NET
languages
Minimum Requiremehnt: Compiler that compiles ruby code to .NET
assemblies. This would be quite difficult, as CLI and the .NET type
system are not at all designed for dynamically typed languages such as
ruby. You would have to decide whether to implement types yourself,
or to rely on dynamically adjusting .NET types, which is possible but
might be slow and/or complicated.

---

Level 1 should be just a matter of using the common language runtime
hosting interface and calling CorBindToRuntimeEx to get an
ICorRuntimeHost, then picking a module and loading it into an app
domain etc etc. Very easy, if all you want to do is call methods one
after another -- if you want to switch back and forth between ruby
code and C# code I don't know what problems would arise.

Level 3 would be a very large project and would probably involve an
industrial amount of work. Although the .NET runtime can support
modifying a type on the fly, I don't think this would actually allow
ruby types to be represented 1-to-1 by .NET types. Perhaps the .NET
lisp projects have some insight into this.

Level 2, my favorite, would involve:
1--creating and maintaining a ruby grammar with c# or c++ bindings
(antlr?)
2--implementing ruby libraries in .net
3--implementing a ruby interpreter that joins (1) to (2) :)
....plus a few other things. Number 1 sounds like the hard part to me.

---

Given that what I mostly want are the features in level 2, and that
level 3 is probably very hard, I would most like to see a project to
implement level 2, and if there were a live project then I'd try to
join in with it (hint hint). The abandoned one (NETRuby) really
looked good, although keeping the grammar in step with that of ruby
itself is a task I can't handle.
I hope your grandchildren won't use Windows anymore.

Of course not, I was just joking. In fact they'll use Open BeTRON,
the BTRON-based open source version of BeOS which is currently still
secret -- oops.
 
G

Gawnsoft

Saluton!

* Gawnsoft; 2003-07-21, 17:46 UTC:

I don't try to sketch an image of what computing will be in 30 years
because that is doomed to fail.

Hmmm. For a 30 year timespan, perhaps.

But for a 20 year timespan, it's not so difficult.

After all, DOS compatibility in the newest Microsoft Operating system
lasted that long (or perhaps very slightly longer)

Currently, the realm of handheld devices is, in part, recapitulating
the progress of home computers of the late-70s to mid-90's, in terms
of UI, screen resolution, and sound capabilities.

Lots of bigger computers are still running upgrades or re-hashes of
their 20 & 30 year old OS's.

Only one aspects seem to be
relatively sure: Whatever will be the operating system in 30 years or
so will almost certainly be no 2D system. Silicon Graphics is working
on a 3D user interface and so is Microsoft. Even if Microsoft happens
to keep a 90% share of the market it is *very* unlikely that their OS
will be called 'Windows'.

Maybe we are going to use the successor of Windows, maybe we are
running Linux, or maybe we are struggling with the Chinese OS that we
have to use. Who knows?

It is also not too likely that we will be using Ruby - remember how
much changes in programming language design took place since the
early 1970's.

And yet things like Cobol, Lisp, Forth and C are still used heavily
even today.


Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
 
M

Mauricio Fernández

Saluton!

* Yukihiro Matsumoto; 2003-07-22, 13:47 UTC:

Good one but I am pretty sure that this will not be the sole change.

matz is in a somewhat unique position to foresee whether Ruby will
undergo changes in the future or not :)

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Are Linux users lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?
-- Matt Welsh
 
O

Oliver Cromm

Quoth Josef 'Jupp' Schugt:
* Yukihiro Matsumoto; 2003-07-22, 13:47 UTC:

Good one but I am pretty sure that this will not be the sole
change. I am not sure about COBOL but FORTRAN did undergo quite a
number of changes.

There was an anecdote when FORTRAN 90 was being developped. An insider
was asked what kind of language the new FORTRAN would be, and he
answered "I have no idea. The only thing I know is it will be called
FORTRAN."
 
J

Josef 'Jupp' Schugt

Saluton!

* Oliver Cromm; 2003-07-24, 21:44 UTC:
There was an anecdote when FORTRAN 90 was being developped. An
insider was asked what kind of language the new FORTRAN would be,
and he answered "I have no idea. The only thing I know is it will
be called FORTRAN."

That's only half the story. The language was not called FORTRAN 90
(in all uppercase) but Fortran 90.

Gis,

Josef 'Jupp' Schugt
 
R

Rodrigo B. de Oliveira

Level 2, my favorite, would involve:
1--creating and maintaining a ruby grammar with c# or c++ bindings
(antlr?)
2--implementing ruby libraries in .net
3--implementing a ruby interpreter that joins (1) to (2) :)
....plus a few other things. Number 1 sounds like the hard part to me.

I'd definitely join such an effort!

Looking forward to use ruby and .net together,

Rodrigo
 
T

Tim Sutherland

Rodrigo B. de Oliveira said:
I feel exactly the same way. When do we start coding? :)
[...]

There is a mailing list
http://sourceforge.net/mailarchive/forum.php?forum_id=34312
for discussing all things to do with Ruby and .NET.

I have code right now which allows you to do things like
require 'dotnet'

DotNet.System.Console.WriteLine("Hello DotNet World!")

foo = DotNet.System.Collections.Hashtable.new
foo['one'] = 1
puts(foo['one']) # -> 1

It also allows C# to call Ruby code.

I'll be making the first "official" release Real Soon Now. (Just need to
deal with packaging issues and get it working on Mono as well as
Microsoft's dotnet implementation.)

Other people on the list also have code they've been using to do similar
things.
 
T

Thomas

I'd definitely join such an effort!
Looking forward to use ruby and .net together,

Hi Rodrigo and anybody else who is interested. There is a mailing list
concerning the effort to make an interop solution using the existing
ruby interpreter and the .net CLR together. Go to the following url to
join: http://lists.sourceforge.net/lists/listinfo/rubydotnet-developer.
Check out the archive at
http://sourceforge.net/mailarchive/forum.php?forum_id=34312.

As you will discover if you check out the archives there are a at
least two teams working separately on this and they have both made
working releases!

Cheers,

Thomas
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top