Why Ruby? (for .NET folks)

Scott Hanselman has been tirelesly plugging Ruby on Hanselminutes. On the most recent episode of Hanselminutes, Carl Franklin asked him point blank at the 19:00 point in the podcast:

What’s so great about Ruby that C# or VB.NET can’t do? What’s so cool about it?

That’s a really hard question to answer, especially if the question comes out of the blue and you haven’t been practicing the answer. I know that I’ve been hit with it quite a few times, and the answer that I gave is much like the answer that Scott gave – it’s elegant, the code says what it does and nothing else. But that’s a lot like saying my M3 is a great car because it’s pretty and it handles great.

Surely there’s more than just that? So in the interests of practicing my answer to that inevitable question, here’s my take on why Ruby is great, with a slant towards .NET developers.

There are a lot of reasons to love Ruby as a language. I’m not going to try and cover everything here; I’m going to focus on one thing that I happen to like about Ruby, and how it rocked my world. That one thing is Domain Specific Languages.

.NET developers use domain specific languages all the time, probably without really realizing it. HTML, ASP.NET markup, NAnt scripts, CSPROJ/VBPROJ files are all examples of domain specific languages. Domain specific languages are great when you work in the problem domain that it was intended for. After all, they are tailored specifically to that domain. But after working in that problem domain, you almost always want to do something that’s beyond the scope of that domain specific language. That’s when the trouble (and the hacks) start coming.

For a concrete example, consider NAnt. It’s a DSL that’s tailored towards managing complex builds and the interdependencies between targets. Ideally, you declare the dependencies and you let NAnt deal with figuring out what to do. However, at some point you wind up requiring more than what NAnt can give. That’s when you start adding procedural hacks into the language, like the foreach task that lets you iterate over a collection of elements. As your requirements morph (like you want to use your NAnt script to automate deployment to your web server cluster) you inevitably hit a brick wall, since that was a scenario that NAnt was never designed to solve.

NAnt has a universal escape clause in “write a custom task”. But that now requires you to context switch out of your domain specific language into C#, pull out a compiler, create a NAnt script to manage the build … Once you’re inside the task black box, it’s very difficult to refactor the code in your task across your program (the NAnt script + custom tasks) because your code is now written in a couple of very different languages. That inevitably leads to cut and paste, and duplication of code. That makes your code very difficult to modify and understand(!).

I use domain specific langauges all the time in Ruby. In fact the RubyCLR bridge relies heavily on DSLs. Consider this code frag: