No, in all seriousness after my recent "Ruby.NET Is *NOT* Dead" speech Dr.
Kelly contacted me directly to let me know he was considering what follows.
 And after reading his thoughts and discussing things with him further I
absolutely 100% both stand behind and believe this is the right decision for
*HIM* to make.

I know this is *shocking*, but I actually have quite a bit more to say about
all of this ;-), but today of all days just so happens to be the day I was
born 36 years ago and I have a few friends waiting for my now worthless late
a$$ at a local restaurant so I must scurry on out the door before they give
up on me and find somebody else to celebrate with.

Expect an extended follow-up from me tomorrow.  Gnight' all! :D

On Feb 4, 2008 8:26 PM, Wayne Kelly <w.ke...@qut.edu.au> wrote:

--
/M:D

That may sound silly, but the truth of the matter is that we, as humans,  
tend to attach our emotions to things that really don't matter all that  
much.  As software developers the code we write can very easily become a  
part of who we are, a fact easily seen at a tech conference while we watch  
the presenters gush over PowerPoint presentations as if they were pictures  
of their own children (We've all done it, so that's not a statement of  
exclusivity.) For Dr. Kelly and Professor Gough to have created such a  
fantastically wonderful project to then make the determination that it was  
time to turn their attention elsewhere says a lot about their character, a  
decision I believe they should be commended for making.

I think it's important to consider the fact that when it comes down to it,  
Dr. Kelly and Professor Gough are both computer scientists *AND* educators  
at heart. As both their jobs require them to keep an open mind and a  
finger on the pulse of the industry.  I have no doubt in my mind that  
their decision to forego continued involvement with the Ruby.NET project  
to instead work with the IronRuby team was both difficult and painful. But  
ultimately they had to do what was right for not only themselves but for  
the students that look to them for guidance and direction as to where they  
should place the focus of their studies.  As Dr. Kelly mentioned, the DLR  
and IronRuby are here and here to stay.  It's important that the CS  
students of the world understand this and the best way to understand these  
two important projects is to roll up their sleeves and get their hands  
dirty.

That doesn't mean that the Ruby.NET project should just fold up and die.  
It simply means it was the right decision for them to make, a decision  
that, quite obviously, was not an easy decision to make for either of them.

So then, where from here?

I believe that Ruby.NET is an important project for many reasons, first  
and foremost because it works, works well, and works now.  That said,  
IronRuby and in particular the DLR has completely changed the game for  
dynamic languages on the .NET platform.  We all know that, so there's no  
point in pretending this is not the case.  Ignoring this fact will come  
back to haunt any dynamic language project targeted towards the .NET  
platform.

Relating this to Ruby.NET, the answer as to whether or not the Ruby.NET  
project should live on, in my own opinion, is to focus on the fact that  
Ruby.NET works right now and can act as the perfect foundation for .NET  
developers interested in getting their feet wet with Ruby and for Ruby  
developers interested in getting their feet wet with the .NET platform to  
do just that.  In this regard I see Ruby.NET as a way to start this  
process sooner rather than later while at the same time helping to expose  
where the pain points are such that IronRuby can be a better overall  
project as a result.

But there's more to it than that.

As Ted Neward specified,

In this regard there is a clean separation between what Ruby.NET can offer  
the .NET developer *right now* and what IronRuby *will not* offer the .NET  
developer in the near term future. As such this is one area that I believe  
should be the core focus of the Ruby.NET project moving forward.  But not  
 from the standpoint of creating a competitive Ruby language project for  
the .NET platform -- that would be silly and prideful -- and instead from  
the standpoint of merging the focus of the two projects together in such a  
way that interop between the two code bases is seamless.  In other words,  
and in my own opinion, the purpose of the Ruby.NET project moving forward  
*should not be* one of being a separate project with a separate focus and  
instead,

1) a stepping stone for the Ruby language on the .NET platform that Ruby  
and .NET developers alike can use to get started with Ruby development for  
the .NET platform *right now*.
2) a way that someone can take the same code base they write for IronRuby  
and compile that code into a static and reusable assembly that is portable  
and reusable inside of any CLI-compliant language.

I don't think it was by any strange coincidence that when Dr. Kelly  
created this project on Google Code he chose rubydotnetcompiler as the  
project name, as ultimately that's what this project is all about.  
Ultimately and eventually it may turn out that the IronRuby and DLR teams  
decide to enable static compilation.  And maybe they won't, deciding  
instead to focus their time on making the dynamic nature of dynamic  
languages that much more dynamic than would otherwise be the case.

In the mean time, however, there's the *Ruby .NET compiler* project, a  
project in which I believe should follow the direct path of the IronRuby  
team, making it possible to take code targeted for IronRuby, statically  
compile that code, and reuse the static assembly within any other .NET  
code project.  To me, anyway, this is an area of great desire with the  
.NET development communities and as such the perfect focus for moving this  
project forward.

Thoughts from the communities at large?

--
/M:D

I've been posting bug reports and suggested fixes for a while now, but
I've asked Wayne to make me a project member so that I can make a more
active contribution.

I'm using Ruby.NET heavily in a system being developed for the
automotive industry. It generates code to run in the electronic
control units in mass production cars. I do this by using ERB to
transform templates embedded as resources in .NET assemblies into C
code, and then compiling/linking these to create the embedded
application. I use Test::Unit inside the tool to validate the scripts.
There are some workarounds in there at the moment, but it is a good,
reliable solution - and all in .NET. Interoperability between C# and
Ruby is mostly very good.

IronRuby looks great. I may well switch to using it. But it's a way
off before I can get the same functionality that I have now.

I'd be interested to hear from the other members about how they want
to proceed, and I hope to become a useful contributor.

IronRuby code which will throw an error when run via Ruby.NET
---
require 'mscorlib'
require 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll'

a = (1..1000).to_a
s = System::Diagnostics::Stopwatch.new()

100.times {
     s.start
     a.find {|x| x == 1000}
     s.stop
     puts "find took: #{s.elapsed.ToString}"
     s.reset

The modified code that successfully runs via Ruby.NET
---
require 'mscorlib'
require 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll'

a = (1..1000).to_a
s = System::Diagnostics::Stopwatch.new()

100.times {
      s.Start
      a.find {|x| x == 1000}
      s.Stop
      puts "find took: #{s.Elapsed}"
      s.Reset

The difference, quite obviously, is that the IronRuby code will accept  
lowercase method names for methods that would otherwise require an  
uppercase reference if called via their C# or VB.NET counterpart.  These  
are the kinds of things we need to discover and "fix" to ensure that the  
developer doesn't stumble across road block after road block when  
attempting to interop between IronRuby and Ruby.NET.

Some might argue that being forced into adapting to the IronRuby way of  
doing things shouldn't be a requirement, but from my own perspective the  
end goal is not to differentiate Ruby.NET from IronRuby, and instead to  
make them completely transparent to one another.  I, like everyone else on  
this list (that I am aware of, anyway), have a tremendous amount of  
respect for John Lam, John Messerly, Tomas Matousek, and Haibo Luo (has  
the IronRuby team added any new members as of late that I'm missing?), and  
it's quite obvious that Dr. Kelly and Professor Gough feel exactly the  
same way.  These guys don't make their decisions lightly, and given the  
fact that the IronRuby project is an open source, open community project  
it's not like there hasn't or isn't going to be proper communication  
between the MSFT Mothership and the communities at large when it comes  
time to making decisions related to what syntax will be supported and why.

As such, I personally believe that no matter what the decision ends up  
being for any given syntax or implementation of a language feature, it's  
our job as the Ruby.NET development community to keep up the pace.  To  
think of this another way, if the Mono Project members can keep up the  
pace with the entire .NET platform then there's no reason we can't keep up  
the pace with the IronRuby project.

--
/M:D

I've been receiving lots of questions regarding the status of the Ruby.NET project.

I believe a number of people are keen to continue the project and I completely support this.

If this is to happen however, we (you) need to send out a clear message that the project is not dead
and that others are continuing with it. It would probably help to appoint a new leader.
As the most vocal advocate for continuing the project, David Peterson would seem the logical choice.
There does however, I believe, need to be an open discussion about what the project is trying to achieve
and what its direction will be in the short term. It may also be interesting to find out how many
people are still interested in contributing and in what capacities.

Please respond with your thoughts.

Areas of primary focus for the Ruby.NET project,

* Facilitating static compilation of Ruby code.
* Ensuring 1-to-1 compatibility with IronRuby.

As a secondary area of focus it seems to me that experimentation with new  
language and platform features could be really beneficial from the  
standpoint of R&D for the Ruby language.  For example, similar to the work  
being done on Rubinius, I believe that experimentation with concurrency  
via Actors/Agents could help pave the way to finding this a core part of  
the Ruby language in years to come.

In this regard and capacity (R&D), working directly with the Rubinius team  
I believe should be at the center of our focus moving forward.  I've Cc'd  
Pat Eyler and Charlie Nutter as I believe they both will have keen  
interest in helping to open up the lines of communication with the  
Rubinius project.  Pat, Charlie?

If there is any one message I believe must be broadcast above all else  
it's that the Ruby.NET project should continue forward shadowing the work  
of the IronRuby project as it relates to the language features and syntax,  
not as an alternative Ruby language implementation for the .NET platform  
but as a complimentary extension to IronRuby.  I don't mean that from the  
standpoint of extending directly from the IronRuby code base -- at least  
not yet -- but from the standpoint of extending directly from the features  
and syntax pushed forward by the IronRuby project.  In other words, if as  
a developer I write code targeted towards IronRuby that same code should  
run exactly the same via Ruby.NET when compiled into a .NET assembly,  
whether that be an executable or DLL.

--
/M:D

Perhaps one of the continued appeals of Ruby.NET is that it is
community-driven not vendor-driven. It would be great to be able to lift
up a Ruby application off YARV, put it onto JRuby, xRuby, Ruby.NET,
IronRuby, or Rubinius and have it work the same.

* Facilitating static compilation of Ruby code.
* Ensuring 1-to-1 compatibility with Ruby.
* Ensuring as great a level of 1-to-1 compatibility with IronRuby that's  
possible after meeting the above two priorities.

???

Thoughts from the community at large?

--
/M:D