IronRuby – A compelling story

The Problem

Since I started programming in .net, one of the most compelling arguments I have heard for the framework was multi-language support.  That is, the ability for a developer to choose the best language for the job and have interop between other developed bodies of code is very very powerful.  The reality however is that aspect of the framework is rarely used.

In fact, I’d go as far to say that using .net framework beyond C# or VB.NET is rare for most .net developers.  My experience is that people get comfortable solving problems with the things they are comfortable with.  They adapt the problem to their own skill and make it work for them.  Or they don’t.  I don’t want to people to read this and think there is anything wrong with using .net and one particular language.  This is not a bad thing, it’s just not the only story.

Iron* & Dynamic Languages

Microsoft recently put together a team of folk to port the python and ruby languages to .net.  Specifically these projects afford you the ability to:

  • Call python and ruby applications via .net
  • Leverage applications written in ruby or python with the ability to call .net apps.

Cool.  But the 40 million dollar question that should go through everyone’s mind is: why would I ever want to do that? If I can just run either of those languages natively on windows… what’s the point of IronRuby or IronPython?  The answer is simple: the best language for the job.

IronRuby: A love story

So, now the question developers should have is: Okay, why is ruby (or python) the best language for a job?  The answer for me and ruby is simple.  Ruby does things in ways that static languages wouldn’t dare dream.  It’s ability to take advantage of metaprogramming & runtime modification is super powerful.  This lets you solve problems in very clean and elegant ways.  It even gives you the ability to change the language itself to better solve problems.  This is a huge win.

That sounds cool, but what does that mean pragmatically?  Lets take unit testing for instance.  Instead of being restricted to mocking things with either virtuals, or by their interfaces, or even not at all because it’s not your source code… what if you could simply override the method entirely at runtime?  Ruby can.  What about being able to write full tests that compile (and fail) BEFORE you ever write a single line of c#?  Ruby can.  What about being able to directly show your customer the results of your tests because they are readable by a normal human being? Ruby can.  What about directly interacting with your code to write tests at all?  Ruby can.

Again, this isn’t to say c# can’t.  Things like PostSharp let you do IL re-writing to modify source you don’t own.  Mocking frameworks like Moq make some aspects of mocking easier.  You could make your test results human readable with some effort.  But that’s not the point really.  The things listed above are natural in a language like ruby.  You get it for free, no charge.  I would even go as far to say that concepts like BDD are far more mature in Ruby than they are in c#.  Cucumber is sweet.  And guess what? IronRuby lets you bridge the two.  Best of both worlds kinda deal.

I have lots of other ideas on why this matters, I will post more later (with source code too).  Till then, explore IronRuby.  If for no other reason than expanding your statically compiled mind 🙂


Post a comment or leave a trackback: Trackback URL.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: