Ruby is a bad language. It encourages programmers to use dirty techniques, so-called bad code smells. And the Ruby on Rails framework embraces them fully.

First – please don't consider me a PHP advocate, as I've read somewhere. Over the course of my life, I've tasted a whole range of programming languages, not because I had to, but because I wanted to. Programming languages simply fascinate me. The one closest to my heart is probably C♯. It's a platonic love, though – I've never written anything in C-sharp. Maybe that will change.

My soft spot for C♯ might partly stem from the fact that its author is Anders Hejlsberg, a man whose accomplishments have greatly influenced not just me, but the development of computer science as a whole. And I didn't even know about him until recently – only while reading his biography did I keep repeating to myself: he's behind this too?

Another language high on my favorites list would be Java. And PHP? Well, it's a good language – that I cannot say 🙂 The trouble is that, unlike C♯ or Java, it isn't standardized and its shape is de facto determined by the (only?) interpreter. And that interpreter doesn't have my trust. New versions introduce new bugs, so PHP updates on web servers cause programmers sleepless nights. Only thanks to its unrivaled ubiquity on the best web platform (Unix) did it become my primary programming language.

OOP, Slightly Different

The JavaScript language (or ECMAScript, if you prefer) is often criticized for its approach to objects. It's a prototype-based language – classes don't exist in it, and inheritance is replaced by prototyping. This is a technique that seriously violates fundamental principles of OOP, namely encapsulation. The resulting problems are explained clearly by Richard Šerý on his short but excellent blog.

Prototype-based languages are therefore suited only for simple scripts, ideally written by a single author. Someone else's code can affect the behavior of yours, and vice versa. There's a risk that after including a new library, parts of your code that have nothing to do with the new functionality will break. That's why JavaScript experts prefer jQuery over Prototype as a framework – jQuery is considerate and stays within its own namespace.

What Does This Have to Do with Ruby?

Quite a lot. Ruby is also based on a similar paradigm. It's very similar to JavaScript. And the popular Ruby on Rails framework behaves just as inconsiderately toward its environment as, say, Prototype does in the JavaScript world.

For JavaScript experts, the previous paragraph is probably a sufficient argument for giving Ruby and Rails a wide berth. For everyone else, here's an example. Karmi writes about Ruby very nicely and readably. He demonstrates the elegance of the language with this example:

print ["banán", "citron", "ananas"].sort.last.capitalize
// prints Citron

Which in PHP (or a similar language) would be written roughly like this:

$a = Array("banán", "citron", "ananas");
sort($a);
print ucwords( end($a) );
// prints Citron

A slight digression: this approach can be emulated in PHP too. The only difference is that PHP lacks the beautiful literals that Ruby has (i.e., you write [1, 2, 3] and that creates an object). If I define the appropriate classes, I can write in PHP:

print MyArray::factory("banán", "citron", "ananas")->sort->last->capitalize;
// prints Citron

But back to Ruby. There's one absolutely fundamental difference between the two examples. While in PHP, the output is always Citron, in Ruby you can only hope so!

In Ruby, just like in JavaScript, you can redefine the behavior of any method in any class with impunity. Including methods that other parts of the system depend on. All it takes is for this to appear somewhere in the code:

class String
	def capitalize
		return 'Gotcha!';
	end
end

And the example above will return Gotcha! instead of Citron. You might ask why a programmer would do something like that? Because they'll do it with the best of intentions. After all, the creators of RoR themselves do such things – and on a grand scale. They “improve” the behavior of a whole range of standard classes, such as String, Array, Hash, Date, Symbol, and so on…

Their intentions are good. But… I'll leave it to your imagination to picture what insidious bugs can arise, how hard they are to track down – especially when the modifying code executes conditionally, i.e., only sometimes. And what happens when you want to use two libraries in one application, each of which modifies the environment (i.e., built-in classes) in its own way.

No, Ruby is not a good language in this regard.

A Pinch of the Positive

Ruby's marketing uses words like happiness and joy of programming. My years of experience as a programmer speak more of despair and headaches. But reality isn't black and white, and I understand the enthusiasm of RoR users.

While everything I wrote about JavaScript applies to RoR as well – it's suited for programming simple applications (from a source code perspective) and combining code from multiple authors is virtually impossible – on the other hand, when you write in RoR:

  • you typically don't combine code, because you build solely on RoR
  • even a “simple” application in RoR can be externally flawless and powerful

Given the dismal state of frameworks on this planet of ours, the enthusiasm with which Rails was received is understandable. Yes, it's a good framework. Better ones exist. But using Rails means becoming its slave, creating entirely under its direction.

(Although my opinion is highly unpopular, I stand firmly behind it. I don't need to debate it. Nor did I intend to provoke anyone – everyone should use whatever suits them. If you'd like to write a comment, please use your own blog to do so. Thanks for understanding.)

Related: