Ruby.NET Interview With M. David Peterson

M. David Peterson came out to the UtahValley.rb’s ‘Ruby on .NET’ night to represent the Ruby.NET project a while ago. The IronRuby presentation ended up going longer than we’d scheduled, so I wanted to ask him some questions about his view on the two Ruby projects and Ruby.NET specifically.

---

How much are the IronRuby and Ruby.NET projects working together?

M. David As far as I know, there is no collaboration, something I would LOVE to see fixed, ESPECIALLY as it relates to the RubyLib’s themselves, as for what should be obvious reasons being enabled to use the various RubyLib’s via both Ruby.NET and IronRuby would benefit both projects as well as developers writing Ruby code targeted at the .NET platform.

Where/how could they better cooperate?

M. David The development of both the RubyLib’s as well as extensions to those libs would be the ideal collaboration point, in my opinion. One of the future pain points that is bound to come into fruition is the (ability|inablity) to use code targeted for Ruby.NET w/ IronRuby and vice versa. For example, making an external to the .NET Framework Class Library (FCL) should work exactly the same regardless of the runtime engine/compiler being targeted. If it doesn’t, both projects are going to find friction in the development communities as it relates to adoption of either platform.

To me, anyway, the two most important points for both the Ruby.NET and IronRuby projects are,

• Can I quickly and easily run my existing Ruby code, w/o change, via both runtime implementations?
• If I make a call to the .NET FCL in my code, will that code run the same via Ruby.NET and IronRuby?

What’s the easiest way to get started with Ruby.NET for Windows, Mac, and Linux users?

M. David Begin with a specific development task and then start writing the code to make that work. Attempting to get an existing Ruby library to run can be frustrating due to the fact that the Ruby.NET project as it relates to full compliance with the Ruby language is not complete. And the real key benefit to Ruby.NET is the interop layer with other .NET languages such as C#, VB.NET, IronPython, etc. So while there is still more work to do before full compliance with the Ruby language is achieved, there is still some amazing things you can do as it relates to using the Ruby language to build and extend from existing .NET libraries.

What are some ways the Ruby.NET team is working with the larger Ruby community?

M. David Let’s just say that’s a work in progress. ;^)

What more could they be doing?

M. David A lot! Joining in the efforts to ensure cross-engine interop is critical in my opinion, so taking part in the ongoing efforts to develop a test suite that ensures proper compliance is therefore critical.

In addition I think it would make a lot of sense to join in the efforts of defining the future directions of the language itself. .NET has a lot to offer when it comes to providing solid use cases for language features. I think the biggest mistake any language design team could make would be to ignore the fact that with .NET there is a HUGE base of languages and therefore language features to pick and choose from that could benefit them.

Why should we trust Microsoft?

M. David You shouldn’t. At least as it relates to whether or not MSFT will do the “right thing” when that right thing is a choice between what’s right for the development community and what’s right for their share holders. MSFT is a profit driven company and will make their decisions based on what will generate revenue and what will not.

But in the case of the MPL’d projects, you don’t have to trust them. The .NET open source communities are active and vibrant, the Mono Project representing the most active and vibrant of them all, filled with passionate open source .NET developers. If MSFT falls short on any of their MPL’d projects, the community will jump in and either fork the project and/or fill in the holes as needed. Seo’s IronPython Community Edition project is a good example.

Ruby is a community-based language, with several OS implementations already in existence. With the added value of being able to interop directly with a HUGE base of development languages, the benefits of continuing forward with the Ruby.NET project regardless of what MSFT might do is obvious. Of course Ruby.NET is completely independent of MSFT and as such, there’s really no reason to be considered with what MSFT does or does not do.