When Dr. Kelly first broke the word that he was going to stop working on the Ruby.NET project, M. David Peterson and Ted Neward replied to say that they thought there were still reasons for people to keep working on the project. (I wrote about this flurry of emails here.)
M. David Peterson also wrote that he’d be writing a longer explanation of his thoughts in a day or so. That time has come, and I think it’s worth examining this longer email.
Peterson starts out by commending Dr. Kelly for making the difficult decision to begin supporting the IronRuby platform at the expense of the Ruby.NET platform.But, as he says, “[t]hat 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.”
He goes on to talk about two ways that Ruby.NET can still play an important role:
- as “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.”
- as “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.”
The first is mostly a matter of Ruby.NET being ‘closer’ to a running Ruby platform right now than IronRuby, a claim I’m not in a good position to judge. The second is the more important. Peterson wrote:
One of the most commonly asked questions on the IronPython development list — IronPython as we all know being the basis of what brought about the DLR — is “Can I write my libraries in Python and then call those libraries in my C# or VB.NET code?” While the answer is a bit more complicated than this, for the most part the answer is “Probably not.” This is one area of the DLR that both the IronPython and IronRuby teams have specified would be nice to have, but at present time is a non-goal for the 1.0 release of the DLR and the projects based on that release.
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 …
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.
Whether as an interim move, or as the only static compiler for Ruby on the .NET platform, this kind of interoperability is really important. Making it work well is going to require a lot of communication between the new Ruby.NET team and the IronRuby folks (and probably more CLR folks that I don’t know about). Hopefully everyone involved can carry it off.