After Demo Camp the other night I was talking about the merits of Ruby as compared to Java for web development. At the time I was perhaps a few too many beers into the night to speak coherently on the issue, and it was rather difficult to communicate over the karaoke. I figured I’d take another crack at the topic here with a more thought through response. I was originally going to write this as a Ruby vs. Java comparison, but upon starting to write I realized I really don’t have sufficient Java expertise to speak with any authority, so instead I’m just going to give a run down of why I like the web on Ruby. I invite comments/comparisons on the subject.
Let me start this by saying that I am not generally a language evangelist. I don’t think there is a perfect language, I also don’t hate any languages I’ve used. Languages, in my opinion, generally have a niche they are well suited for, and also usually can be used for nearly any problem with a bit of work. They always have strengths, weaknesses, and trade offs to be made. With all of that in mind I think the choice of language for a project is often far less important than the choice of people, the definition of requirements, the development methodology, etc. Please keep in mind that when I express my whole hearted support for Ruby it isn’t meant to imply that Ruby is always the best choice, that other languages are inferior, or that if you disagree with me I will be offended in any way. I always enjoy a good debate of ideas and there is no way I will address every area of contention in this article so please comment away on what I missed or why I am foolish.
I’ll start by addressing a couple common complaints about Ruby. I think the most obvious flaw with Ruby is its performance. It is a slow language beset by historically lackluster implementations. The problem with this as an argument against web development (as opposed to 3D rendering) is that in the big picture for web development processing performance means essentially nothing. Performance of web apps (at least the ones I work on) is dominated by database access times. On top of that it’s not really performance that matters, it’s scalability. Serving web pages scales incredibily well from the CPU side of things so one can always throw more processors at the problem.
Another complaint against Ruby is maintainability. This complaint was specifically made to me after Demo Camp and resulted in much of my floundering for an answer. One of the big reasons I was slow to come up with counter arguments as to the benefits/trade offs that warrant this, is that I don’t really believe it’s true. I took some time today to look for evidence in support of the claim, and instead found an article by Ola Bini, “The Maintenance Myth”, that sums up my own feelings on the issue quite well.
Basically I think there are two things that really prevent maintenance from being a disproportionate problem in a well organized dynamic language project. The first is that you write fewer lines of code. The estimates as to how many fewer vary extensively; but dynamic languages are more expressive than static ones. Fewer lines of code means fewer places to go wrong, fewer places to look when making changes, fewer lines of code to understand when you read the code later.
Second, dynamic languages lend themselves to DSL’s. DSL’s are another source of embarrasment to me from Wednesday night as when I tried to explain how awesome they were, I couldn’t even manage to explain what they were. For those not familiar with the acronym it stands for domain specific language. Basically it means you have a nifty little framework specifically tailored to your problem that allows you to describe instances of your problem in a way that makes sense for that specific problem. The closer your language is to the problem you are solving, the less work it is to think about how to solve the problem. In a statically typed language you typically solve a problem by instantiating a factory, and then telling that factory to build an object, and then asking that object for the answer. In a dynamic language you do something like find_restaurant :type => :pizza, :budget => 25, :location => 'Edmonton' and it returns you a list of restaurants that fit the constraints. The difference is both small and large. You use the same starting information and achieve the same results, it’s all about the extra thoughts/lines of code required to do it in a static language. Without the extra considerations there is significantly less potential for bugs when writing it, and for misunderstandings when reading and learning it after the fact.
I’m not making the argument that dynamic languages are inherently more maintainable than static ones. Static languages have advantages in tools: IDE’s that can reason intelligently about the code, compilation that removes an entire class of bugs before runtime, and generally superior debuggers. The problems one faces though are different and I have never seen in play out that it is inherently easier to maintain static code. The least maintainable piece of code I work with is written in Java. It is unmaintainable because it was poorly designed not because of any choice about language.
Based on these arguments I claim that Ruby falls into the category of languages that can be acceptably chosen for web development. This is a large class of languages and the choice between them essentially comes down to what language will developers be the most productive in. This is a question heavily influenced by the skillsets of the developers available, the development methodology, the culture of the company, and the existence of preexisting libraries suited to the problems at hand.
In the case of Nexopia when we made the decision to switch to Ruby, we were a group of young developers, with backgrounds in a diverse set of languages. We were practicing Scrum development. We were also perhaps a little to keen on doing things ourselves, driving us to discount the importance of preexisting solutions to our problems. As a dynamic language Ruby allowed us to write small amounts of code to accomplish very powerful things. It had a vibrant community all focused on the same types of problems that we were; social media seems to be a primary cornerstone of the ruby world. Within a couple weeks of development (our testing period for the language) we had a basic object relational mapping layer, a routing and controller layer, and a templating system; and we had used them to build a couple basic test projects to great effect. Ruby was fun to develop in and we were getting a lot done quickly. When we met to discuss whether we should go forward with it no one was against it.
It has been a rocky ride since that point, as I said earlier rewriting is not an easy task. The one thing that has held true though is that Ruby has been a joy to write. I spend my time solving interesting problems. Things that would be tedious in other languages are generally addressed in Ruby with a small piece of framework that handles class generation and boiler plate for you. Fixing bugs means fixing the framework and seeing the correction propogate into everything that uses it. When I write Ruby code I never feel like a code monkey, problems that don’t require thought aren’t problems that should need programmers to solve them. Ruby makes this a reality.
In short, the answer to “Why Ruby?” is “because I can”. Powerful language features like OO, closures, metaprogramming, eigen classes (to get all the buzz words out there), help to make it easy to not only solve problems but to solve them elegantly. The drawbacks of Ruby are not drawbacks to development, and in the end I will always choose the language that favours a developer over one that favours hardware. Ruby is a language that makes coding fun, and that is the best reason I think there can be to choose a language.
