Tag Archives: joy

Why I love Ruby (Part 1)

So, it occurred to me that so far, my posts (both of them) have been pretty negative. So I thought today, instead of ranting about something I detest, I’d rave about something I love. And that something is Ruby. I looooove Ruby. I got into Ruby because of the Rails web application framework, but my love of Ruby goes so far beyond Rails. Let’s start with a quote from Yukihiro Matsumoto (Matz), the creator of Ruby:

For me, the purpose of life is, at least partly, to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, so Ruby is designed to make programmers happy.

Ruby definitely brings the joy. Oh, does it ever bring joy. Have you ever coded in something like PHP or C++, and felt like you were fighting the language to accomplish your task? This common phenomenon is absolutely absurd. Tools should make the job easier. This bears repeating:


I like tools that make the job easier. This is why I only use Unix-like operating systems, because they have many small, convenient tools that make life infinitely easier. I’ve never understood how people could assert that Unix (or Linux, etc.) isn’t user-friendly. It’s the most user-friendly OS that has ever existed… it’s just selective about who its friends are. But, back to Ruby.

Ruby knows exactly who its friends are: programmers. It’s the most programmer-friendly language I’ve ever worked with. It’s designed from the ground up to operate on the Principle of Least Surprise. What this means is that the irritating gap between what you want the computer to do and what you actually told it to do becomes a lot narrower.

Ruby was also developed slowly, and thoughtfully, from the ground up, using the best-of-the-best from multiple programming paradigms, and from the best-of-breed languages from each of those paradigms:

  • Smalltalk: Smalltalk was the first object-oriented programming language, invented by Alan Kay at Xerox PARC in the late ’70’s and early ’80’s. Ruby draws its pure-OO object model from the language that started it all, and this adds to the joy of object-oriented programmers.
  • Lisp: Probably the first full-fledged functional programming language, Lisp has a storied history of use in academia and the AI community. From Lisp, Ruby inherits its concepts of closures, lambda functions, and tail call optimization, which make it possible to do very function-oriented things in this pure-OO language… I won’t go into the guts of why tail-recursive functions are a Good Thing, or why closures add to programmer joy… but the guy who said “Ruby is like Lisp, but with syntax” wasn’t wrong.
  • Perl: Ruby has less of the Perl-paradigm than it has of the paradigms of Smalltalk and Lisp, but it shares much of the Perl-nature. Ruby has powerful text-processing and regex capabilities which were non-existent before Perl (don’t even bring up sed and awk). It also borrows some rather random things from Perl; Gems follow the CPAN paradigm to a degree, Ruby can handle shell one-liners much like Perl, and Ruby is actually great at most of the system administration tasks that Perl started to make easier in the late ’80’s. Procedural Ruby scripts even tend to look a bit like Perl scripts, but maybe that’s just because so many of them are written by old Perl hackers.

So, Ruby took the best concepts from the best of the best, and worked them into a masterpiece of language design. Compare the evolution of something awful like, oh, I don’t know, PHP.  Jeff Atwood of Coding Horror and Stack Overflow fame puts it rather well:

From what I’ve seen of it, PHP isn’t so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre.

PHP first emerged as a subset of Perl for embedding code inside of HTML, mostly. Think about that for a minute. Now think about Unobtrusive JavaScript, and the whole thrust of behavioral separation, getting the code OUT of the markup. Surely, we now realize that PHP was misguided from its inception? But this is beside the point. What PHP should demonstrate is that a programming language should evolve programmatically, not organically. PHP was never planned, it was just vomited upon the world as a mass of kludges and spaghetti code.

The development of Ruby was the polar opposite of this. Ruby was planned, designed for the sake of programmer joy. And programmer joy is, IMHO, derived from a few core experiences. I don’t claim this to be a comprehensive list, but some of those include:

  • Not having to re-invent the wheel every damn day: Ruby makes it a breeze to write re-usable code. If you find yourself violating the DRY principle while coding in Ruby, you’re doin’ it wrong.
  • Avoiding repetitive, unnecessary keystrokes: repetitive-stress injuries are an occupational hazard. If a language reduces the number of keystrokes you’re having to enter by an order of magnitude, that’s a Good Thing.
  • Principle of Least Surprise: I mentioned this earlier. Ruby’s core libraries follow class and method naming conventions fairly rigidly, so you know that a method anding in ? is going to return a boolean, and a method ending in ! is going to modify the object in-place. And this principle has been followed quite closely by gem (library) authors. So I know if I call @variable.foo?, it’s going to return true, false, or possibly nil, but not a String or Float or anything else.

This post has outgrown my intentions for it, and there are so many more resons to love Ruby, that I’m going to have to continue this later… look for Part Two soon.