Is IronRuby mathematically challenged?

Ruby is a remarkable language, and even companies like Microsoft and Sun, end up taking notice of, and embracing, it rather than opting to fight against its widespread appeal. More than ever Ruby is seen as an unwritten (sic) specification that is not limited to its official implementation. The main current interpreter is suboptimal as we all know. This scenario has one big advantage, though it may appear as a disadvantage at first: projects keep popping up in a quest to generate an efficient and widely adopted interpreter/virtual machine. Generally speaking, this diversification is a risky business because it can’t help but divide the effort put forth towards it by those within the community. Years of Open Source history have taught us though that options are usually a good thing and the majority of development efforts will still go towards the most promising projects. We allow mutations of an original idea into multiple projects, and in turn let a sort of natural selection decide their destiny and long term adoption.

In the specific case of Ruby, besides the current interpreter, JRuby is the most prominent implementation. Other notable mentions are Yarv – the work in progress at the core of what will be Ruby 2.0 -, Rubinius, Ruby .NET (formerly Gardens Point Ruby .NET) and now IronRuby. JRuby and IronRuby are directly developed and promoted by the producers of the two mainstream platforms, respectively Sun and Microsoft. Their interest goes beyond the simple issue of putting out a Ruby implementation which performs well, that is already being answered by Yarv. What they bring to the plate is the possibility of integrating Ruby with the existing code base respectively for Java and .NET. This is a key point, because let’s face it, despite its success, Ruby is not going to replace Java or C# in the mainstream market over the next few years (if ever). Interoperability is exciting as it is synonymous with removing the barrier of entry to Ruby for the Enterprise world and non-Open Source based shops. Simply stated, we’re not asking them to toss their Java or .NET investments out the window, but rather we’re enabling them to take advantage of the rapid development which is possible through Ruby – while still using very refined tools, the existing code base, and a platform which they are accustom to.

By now you should get that I’m highly interested in the development of these implementations, particularly for the .NET and Mono platforms where beautiful GUI development works well. And while I’m afraid that Microsoft will continue to strongly influence the “natural selection” process that we covered above, limiting the Ruby.NET project which is about to be open-sourced by Queensland University, I can’t help but feel excited about IronRuby. So why the mildly negative title of this article, you may ask. On July 23th, John Lam announced the release of a first pre-alpha version which is available for download. This arrived sooner than expected, and Scott Guthrie – General Manager within the Microsoft Developer Division – even showed us some shiny windows made with IronRuby and WPF. Not only this, John also announced that they will be soon taking contributions for the IronRuby libraries and that they will host the project at RubyForge (wow, they must have Lawyers 2.0 as well :-P) and that they have some interesting micro benchmarks. This is all great, so again what’s the issue? Well, I was very interested in trying out IronRuby, but I immediately discovered that it is very crippled from a mathematical standpoint, even for a pre-alpha version. I have a lot of respect for John Lam and the people working on this, and I do understand that it’s a first drop of code and therefore basically in its infancy and that in turn we can’t, in all fairness, have unreasonable expectations at this stage. However after running some simple tests, it is clear that a lot of work is required in order for this project to live up to the buzz that is being generated online about it, when you take into account that even some simple arithmetic functionalities are either flawed or missing altogether.

Some basic calculations

If you build IronRuby and run rbx.exe, you will find yourself in a .NET enabled version of irb. By the way, it may be a good idea to change that name as it is the one already adopted by Rubinius and possibly by spyware on Windows. Let’s see what happens when we do some basic calculations:

As you can see, this incorrectly converts 3.0 to the integer value and then performs an integer division. If you run this in the official Ruby interpreter, and presumably in any other implementation, you will get 0.333333333333333. Trying to be forgiving on this one by using a floating point number for the numerator as well, makes things worse:

We can’t divide two floating point numbers in IronRuby? OK, let’s stick with Fixnum (small integer numbers) and perform another basic mathematical operation: the exponentiation.

This didn’t work either (of course, we were expecting 8 as a result). So while calculating several multiplications, I noticed another problem:

The safety of performing calculations with big numbers (without having to deal directly with overflows) is an important aspect of Ruby. While the Bignum class appears to be defined:

It is clear that it is not implemented and it’s only there as a placeholder at the moment:

Conclusion

Please don’t take this as an attempt to bash IronRuby, as it most certainly is not intended as such. I have great expectations for this project and look forward to writing lots of Ruby code running on both .NET and Mono through IronRuby. Also, the developers have done a great job at coming up with a preliminary implementation in a very short amount of time. However, when you read about IronRuby and talk about it as the next great thing in the Ruby world, keep in mind that they were not kidding when they called it a “pre-alpha1”. I look forward to documenting the progress of this project on this site, and I will definitely continue to keep an optimistic eye on IronRuby.