You Used Ruby to Write WHAT?!
Deciding when to use any language--including Ruby--depends on the appropriateness to task and the amount of yak shaving necessary. Zed Shaw explains when Ruby's MRI or JRuby is the best language for the job, and when it really isn't.
Sat, March 01, 2008
CIO — Ask any programmer what his favorite language is good for and he'll yell, "Everything!" At least until his next favorite language comes along, which is also good for everything. The truth is: Any language that's Turing Complete and supports enough language features can solve any problem. The difference between languages and their usefulness is a matter of degrees of "yak shaving."
"Yak shaving" is a programmer's slang term for the distance between a task's start and completion and the tangential tasks between you and the solution. If you ever wanted to mail a letter, but couldn't find a stamp, and had to drive your car to get the stamp, but also needed to refill the tank with gas, which then let you get to the post office where you could buy a stamp to mail your letter—then you've done some yak shaving.
Some programming languages and some platforms (I'll make the distinction in a bit) minimize yak shaving. To create a simple language in Ruby, I have to find multiple undocumented libraries, install byzantine dependencies, track down build errors, find conflicts in things called "hoe" (which needs rubyforge which needs rake which needs Ruby), verify which version of Ruby I'm using, or try the undocumented lex and yacc integration, find out about Coco/R or other projects, install multiple non-Ruby packages, have the right libraries (again), talk with various people in IRC who don't want to talk to me—and then, after a few weeks, I might have just the harness done. Conversely, using ANTLR, without much fuss I can prototype an entire new language in a weekend and deploy it to just about any computer. It's not completely effortless; I can usually create a small parser for a protocol or mini-language in about a day or two using ANTLR and one book by Terrence Parr.
It's this distance between problem and solution that makes one language more suitable than another for a given task.
Aside: Sure, for the ultrageek in us, these yak-shaving expeditions can be fun, depending on the platform. I personally wouldn't do anything more complex than ant build on Java, but on Factor, Lua, Python or Ruby I'd gladly spend a weekend hacking at something just to prove I could do it (or to use it for something especially nerd powerful).
However, the platform is not the language. A programming language can be divorced from the physical computer it runs on. You can run multiple languages on virtual machines, such as the Sun Java Virtual Machine (JVM), Microsoft Common Language Runtime (CLR), NekoVM and LLVM; you can even host Forth in JavaScript in a browser. The separation of the language used to describe computation from the actual computational device means that programmers can choose various languages for a task, yet IT management can keep deployment platforms standardized and cohesive.
Why is this relevant to Ruby? Recently, there's been a huge push to take Ruby onto both the JVM and the CLR systems. Ruby's popularity means that companies like Sun, IBM and Microsoft want to add the language (and others, such as Python) to their platforms. This keeps programmers writing code for the vendors' platforms and keeps computers in the data center running their (expensive) software. Based on the adoption of Ruby on Rails I've seen for internal projects in 2008, this is a smart move.
In Ruby's case, the ability to host on multiple platforms means that whatever C, Java or C# can do, Ruby can do as well. The same advantage applies to Groovy, Boo, Python, Scala and JavaScript. What is left is a matter of style and reducing the number of yaks in the field you have to shave to get the job done.
