Posts Tagged ‘ruby’

Understanding the Ruby object model

August 7th, 2011 31 comments

Not a very long time ago, I found the Ruby object model very confusing. Part of my problem was that I was trying to model the relationships as a directed acyclic graph, whereas in reality, the model contains cycles. I’m guessing that others have found this confusing, so I’m going attempt to explain how it works in a way that my past self would have understood! Note that this is a basic explanation, and glosses over higher-level concepts like the eigenclass/metaclass (I’ll leave that for a later post).

Different things in Ruby

There are just a few things that exist in Ruby that you need to understand to really grok its object model.


Everything is an object. You can’t get very far into Ruby-land without hearing that phrase. It’s true though, everything in Ruby is an object. The interesting thing is how those objects are linked together and classified.


All objects are instances of a class. There are three special classes that are the key to understanding the Ruby object model: Object, Module and Class. More on them later.


Like I said before, it’s the links between the different objects that explain how the Ruby object model works.

Instance of/class

All objects have a class – they are instances of that class. That means that whenever you have a class, you can call .new on it to get an instance. And whenever you have an instance, you can call .class to get its class. This seems obvious, but it can get confusing when you remember that everything is an object, and so everything is an instance of a class.


All classes have a link to a superclass. If you don’t explicitly inherit from another class in a class definition, that class will inherit directly from the Object class.

How they fit together

Here’s some code to play with:

class Animal

class Dog < Animal

fido =

Once you know what the pieces and the relations are, it’s fairly straightforward to piece them together. All classes are an instance of Class. That includes the class Class, so there’s a circular relation there (which isn’t a problem).

Dog will basically have the following inheritance hierarchy (the superclass links):

Dog < Animal < Object < BasicObject

(Ruby 1.9 introduced BasicObject as Object‘s superclass.)

The Class class has the following inheritance hierarchy:

Class < Module < Object < BasicObject

Anything that’s a class (so BasicObject, Object, Module, Class, Animal and Dog here) has Class as its class – they’re all instances of Class. Any other objects have their own classes. So fido above will have a class of Dog, 3 has a class of Fixnum, “an awesome string” has a class of String, etc. All those classes inherit from Object ultimately (although classes like Fixnum have their own complex inheritance hierarchies).

To finish things off, here’s a little diagram of what I’ve just described, showing all the class and superclass links.

The Ruby object model

Categories: Programming Tags: ,

The Ruby world is nuts

June 8th, 2011 10 comments

Apparently they started out using God, but switched to Bluepill due to its ability to monitor child processes, such as things spawned by Unicorn.

From Episode 166 of The Ruby Show.

Categories: Programming Tags: ,

Zen and the art of statefulness

February 12th, 2011 38 comments

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing – is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil – objects are merely a poor man’s closures.”

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.

Anton van Straaten

When I first read the above koan some time ago, I didn’t really understand it. I had a very basic idea of closures, but at the time they were just a syntactic oddity to me – something you could do a few cool things with, but not particularly useful. Since then I’ve worked through quite a bit of Structure and Interpretation of Computer Programs and delved into functional programming in JavaScript, which has given me a much deeper understanding of closures. On the other side of the divide, I’ve been doing a lot of Ruby programming, which has helped me grok objects a lot better. I now feel like I can begin to comprehend what the quote was getting at.

My moment of enlightenment came today while reading Test-Driven JavaScript Development and looking at the code for a JavaScript strftime function (abbreviated here for brevity):

Date.prototype.strftime = (function () {
  function strftime(format) {
    var date = this;

    return (format + "").replace(/%([a-zA-Z])/g, function (m, f) {
      //format date based on Date.formats

  // Internal helper
  function zeroPad(num) {
    return (+num < 10 ? "0" : "") + num;

  Date.formats = {
    // Formatting methods
    d: function (date) {
      return zeroPad(date.getDate());
    //various other format methods

    // Format shorthands
    F: "%Y-%m-%d",
    D: "%m/%d/%y"

  return strftime;

The above code uses an IIFE (Immediately-invoked function expression) to produce a function with additional data (if Date.formats was instead declared as a local variable, this would be a better example). If it doesn’t make sense, I thoroughly recommend Ben Alman’s post on IFFEs for an overview of the technique. The code executes, and returns a function. The important thing is that one function is used to define another function and its context.

In Ruby, when you define a class, the class definition is executed as Ruby code, unlike in Java, for example, where a class definition is just a syntactic construct read at compile-time, but not executed in the way other Java code is. A Ruby class definition is read at run-time, and builds up a new class as it is interpreted.

In a lot of ways, Ruby class definitions and JavaScript function-defining functions are equivalent. I’ll give you a little example to illustrate:


var Cat = function () {
  var age = 1;

  function catYears() {
    return age * 7;

  function birthday() {

  return {
    catYears: catYears,
    birthday: birthday

var powpow = Cat();
var shorty = Cat();

//yo shorty, it's your birthday:

alert(powpow.catYears()); // => 7
alert(shorty.catYears()); // => 14


class Cat
  def initialize
    @age = 1

  def cat_years
    @age * 7

  def birthday
    @age += 1

powpow =
shorty =

#yo shorty, it's your birthday:

puts powpow.cat_years # => 7
puts shorty.cat_years # => 14

Strictly speaking, in zen.js I’m returning an object, but the private data and methods of that object are saved in a closure. So, zen.js stores its state in a closure, while zen.rb stores its state in an object. Every time Cat() is called in zen.js, a new closure is created with a unique age. Every time is called in zen.rb, a new object is created with a unique @age. (These two examples aren’t strictly equivalent – each cat in zen.js gets a new copy of the functions, whereas in zen.rb they share the same methods. It’s possible to make the JavaScript version function more like a Ruby class definition, but it takes a bit more code.)

Of course, there’s a lot you can do with JavaScript closures that you can’t do with Ruby objects. And there’s a lot you can do with Ruby objects that can’t be emulated using JavaScript closures. Any time you decide that one is better than the other, just imagine Qc Na hitting you with his stick.

Further reading

Really really simple Ruby metaprogramming

February 5th, 2011 12 comments

Metaprogramming in Ruby has the reputation of being something only the true zen Ruby masters can even hope to understand. They say the only true way to learn metaprogramming is to train with Dave Thomas in his mountain retreat for five years – the Ruby equivalent of this XKCD:

But it’s not that bad. In fact, I’m going to go so far to say that it’s possible to learn to metaprogram in Ruby without even meeting Dave Thomas. Yeah, I know, it doesn’t sound possible. But just you wait…

What is metaprogramming?

Metaprogramming is what makes Ruby awesome. It’s writing code to write code. It’s dynamic code generation. It’s the move from imperative to declarative. It’s a rejection of Java’s endless repetition of boilerplate code. It’s the living embodiment of DRY. Here’s an example:

class Monkey
  def name

  def name= n
    @name = n

I can see you there, in the middle of the classroom, with one arm straining up, the other one holding it up because it’s so damn hard to hold up. OK, Jimmy, what is it? Oh, you don’t need to write all that code in Ruby? You can just use attr_accessor?

Jimmy’s right. That code snippet above could be written like so:

class Monkey
  attr_accessor :name

So, attr_accessor‘s magic right? Well, actually, it’s not. Just like in Scooby-Doo where what looked like magic to start off with turned out to be an elaborate hoax, attr_accessor is just a class method of Module. It defines the name and name= methods on Monkey, as if you’d manually defined them.

And that’s all metaprogramming is. Just a way of adding arbitrary code to your application without having to write (or copy-paste) that code.

An (extended) example

The source code for this example is available in my StringifyStuff plugin on github, which in turn was adapted from Ryan Bates’ Railscast Making a Plugin. Incidentally, if you feel you can improve the plugin, fork me on github!

I’m assuming basic knowledge of Ruby, and some familiarity with Rails would be helpful as well, but not essential.

Have a quick peek at the github repo now – the important files to look at for now are init.rb and lib/stringify_time.

First, stringify_time. This file defines a module called StringifyTime, which defines a method called stringify_time:

module StringifyTime
  def stringify_time *names
    #crazy stuff going on in here

The other two files, stringify_stuff and stringify_money are similar.

Now, init.rb:

class ActiveRecord::Base
  extend StringifyStuff
  extend StringifyTime
  extend StringifyMoney

This extends ActiveRecord::Base with the three modules listed. This now means that any class that inherits from ActiveRecord::Base (e.g. your models) now has the methods defined in each of those modules as class methods.

The StringifyStuff plugin is used like so:

class Project < ActiveRecord::Base
  stringify_time :start_date, :end_date

stringify_time is passed a list of symbols representing the relevant model attributes. It will provide useful accessors for those attributes. Let’s have a look at a simplified version of stringify_time:

module StringifyTime
  def stringify_time *names
    names.each do |name|

      define_method "#{name}_string" do
        read_attribute(name) &&
          read_attribute(name).strftime("%e %b %Y").strip()


stringify_time is passed a list of symbols. It iterates over these symbols, and for each one calls define_method. define_method is the first clever Ruby metaprogramming trick we’re going to look at. It takes a method name and a block representing the method arguments and body, and magically adds an instance method with that name, arguments and body to the class in which it was called. In this case, it was called from Project, so this will gain a new method with the name "#{name}_string". In this example, we passed in :start_date and :end_date, so two methods will be added to Project: start_date_string and end_date_string.

So far so good. Now though, it gets a little bit hairy, so hold onto your horses (or equivalent equid).

In a normal model instance method, you’d access an attribute using a method of the same name. So if you wanted to get the start_date converted to a string, you’d write:

def my_method

The problem with doing this in define_method is that we don’t have start_date as an identifier – it’s held as a symbol. There are two ways to accomplish the above if start_date was passed in as a symbol:

def my_method attr_sym
  read_attribute(attr_sym).to_s #This is a Rails method


def my_method attr_sym
  send(attr_sym).to_s #Ruby built-in method

For simplicity, I’m using write_attribute, but send is useful to know about too.

So, back to define_method:

      define_method "#{name}_string" do
        read_attribute(name) &&
          read_attribute(name).strftime("%e %b %Y").strip()

So, each time round the loop, name will be one of the symbols passed into stringify_time. Let’s go with start_date to see what happens. define_method will define a new instance method on the Project class called start_date_string. This method will check to see if there is a non-nil attribute called start_date, and if so, call strftime on it. This formatted date will be the return value of the method.

Wrap up

That’s more than enough for one day (I’ve been told off for writing kilo-word posts before). I’ll explain the workings of the rest of the plugin in a future post. If you want to learn more, I highly recommend David Flanagan’s The Ruby Programming Language.

Metaprogramming is writing code that gives you more code. It’s a bit like the Sorcerer’s Apprentice; in fact, I think that should be recommended watching for this subject.

Be the Sorcerer. Don’t be Mickey.

Categories: Programming Tags: , ,

Ruby vs JavaScript: functions, Procs, blocks and lambdas

January 15th, 2011 103 comments

In my post Why JavaScript is AWESOME I compared Ruby to JavaScript like this:

A language like Ruby is a toolbox with some really neat little tools that do their job really nicely. JavaScript is a leather sheath with a really really sharp knife inside.

What I was partly getting at was how the two languages handle the passing around of code. Both have their own way of working with anonymous functions. They’ve taken very different approaches, so if you’re moving from one language to the other it can be confusing. I’d like to try to explain the differences. Let’s look at JavaScript first.

JavaScript functions

JavaScript has two ways of defining functions – function expressions (FE) and function declarations (FD). It can be a confusing distinction because they look the same. The difference is that a function declaration always has the word function as the first thing on the line.

//Function declaration:
function doSomething() {
    alert("Look ma, I did something!");

//Function expression:
var somethingElse = function () {
    alert("This is a different function");

The FE can optionally contain a name after the function keyword so it can call itself. I’m not going to go into depth on FD vs FE, but if you’re interested in learning more read Ben Alman’s piece on Immediately-Invoked Function Expressions, which has a good description and some useful links.

You can think of an FE as a function literal, just like {a: 'cat', b: 'dog'} is an object literal. So they don’t just have to be assigned to variables – they can be passed as function arguments, returned from functions, and stored in data structures (objects and arrays). In the end though, there’s only one function type – doSomething and somethingElse are the same type of object.


Ruby is at the opposite end of the scale to JavaScript. Instead of having just the one function type, it has multiple types: blocks, Procs, and lambdas. (There are also methods and method objects but that’s a different story.)


A block in Ruby is a chunk of code. It can take arguments via its funky pipe syntax, and its return value is whatever the last line evaluates to. Blocks aren’t first-class citizens in Ruby like functions are in JavaScript – they can only exist in one place – as the last argument to a method call. They’re very much a special syntactic construct baked right into the language. All methods can received blocks whether they include a parameter for one or not – it will be received anyway, and you can interact with it without it having a name. It can be called with the yield keyword, and you can check to see if a block was supplied with block_given?. Robert Sosinski gives a good example of using blocks from the point of view of the caller and that of the receiver in his post Understanding Ruby Blocks, Procs and Lambdas:

class Array
  def iterate!
    self.each_with_index do |n, i|
      self[i] = yield(n)

array = [1, 2, 3, 4]

array.iterate! do |n|
  n ** 2


If you need a block of code to act as a first-class citizen, you need to turn it into a Proc. That can be achieved with This takes a block and returns a Proc. Pretty cool eh? Procs are useful where you’d want to use a block but you’re not passing it as the last argument to a method. Rails provides a good example:

class Order < ActiveRecord::Base
  before_save :normalize_card_number,
    :if => { |order| order.paid_with_card? }

The :if => syntax shows that we’re passing a hash to before_save. We can’t put a block as a hash value, so we need to make a Proc instead. Other callbacks can just take a raw block:

class User < ActiveRecord::Base
  validates_presence_of :login, :email

  before_create do 
    |user| = user.login.capitalize if

For more discussion on Procs and blocks have a look at Eli Bendersky’s post: Understanding Ruby blocks, Procs and methods.


A lambda in Ruby is probably the closest thing to a function expression in JavaScript. A lambda is created similarly to

lambda { |x| x ** 3 }

Both lambda and take a block and return an object. However, there are important differences in how they deal with their arguments and how they deal with return and break. To talk about that though I’ll need to go back to basics to discuss the reasons for using these self-contained chunks of code.

The reasons for using anonymous functions

There are a lot of good reasons to support anonymous functions in a programming language. In Ruby and JavaScript, the uses generally fall under two rough categories: iteration and deferred execution.

Iteration with anonymous functions

Iteration has a lot of uses – you can sort a collection, map one collection to another, reduce a collection down into a single value, etc. It basically comes down to going through a collection and doing something with each item, somehow. I’m going to show a very basic example of iteration – going through a list of numbers and printing each one.

In Ruby, there are two common ways to work through an array or other enumerable object, doing something to each item. The first is to use the for/in loop, which works like this:

arr = [1, 2, 3, 4]
for item in arr
  puts item

The second is to use the each iterator and a block:

arr = [1, 2, 3, 4]
arr.each do |item|
  puts item

Using iterators and blocks is much more common, so you’ll usually see it done like this.

JavaScript has a for/in loop as well, but it doesn’t really work very well on arrays. The standard way to iterate over an array is with the humble for loop:

var arr = [1, 2, 3, 4];
for (var i = 0, len = arr.length; i < len; i++) {

Many libraries offer support for something like Ruby’s each iterator – here is the jQuery version:

var arr = [1, 2, 3, 4];
$.each(arr, function(index, value) { 

There’s an important difference here between the way Ruby and JavaScript handle the each iterator. Blocks in Ruby are specially designed for this kind of application. That means that they’ve been designed to work more like a looping language construct than an anonymous function. What does this mean practically? I’ll illustrate with an example:

arr = [1, 2, 3, 4]
for item in arr
  break if item > 2 #for non Rubyists, this is just like a compact if statement
  puts item

arr.each do |item|
  break if item > 2
  puts item

These two code snippets do the same thing – if item is greater than 2 iteration stops. On one level, this makes perfect sense – the each iterator takes a block of code, and if you want to stop iterating you break, as you would in any other language’s native foreach loop. On another level though, this doesn’t make any sense – break is used for loops, not anonymous functions. If you want to leave a function, you use return, not break.

Interestingly, if you use return inside a Ruby block, you don’t just return from the block, but the containing method. Here’s an example:

def find_first_positive_number(arr)
  arr.each do |x|
    if x >= 0
      return x

numbers = [-4, -2, 3, 7]
first = find_first_positive_number(numbers)

When arr.each gets to 3, find_first_positive_number will return 3. This demonstrates that in blocks in Ruby, the break and return keywords act as if the block was just a looping construct.

jQuery.each, on the other hand, is working with normal functions (there’s nothing else to work with in JavaScript). If you return inside the function passed to each, you’ll just return from that function, and each will move onto the next value. It’s therefore the equivalent of continue in a loop. To break out of the each entirely, you must return false.

So, in Ruby, break, continue and return work in the same way whether you’re using the for/in looping construct or using an iterator with a block. With a jQuery iterator, return is the equivalent of continue, return false is the equivalent of break, and there’s no equivalent of return without putting extra logic outside the loop. It’s easy to see why Ruby blocks were made to work this way.

Deferred execution

This is where a function is passed to another function for later use (this is often called a callback). For example, in jQuery.getJSON:

$.getJSON('ajax/test.json', function(data) {

The anonymous function isn’t executed until the JSON data comes back from the server. Similarly, with Rails:

class User < ActiveRecord::Base
  validates_presence_of :login, :email

  before_create do |user| = user.login.capitalize

The block won’t be executed immediately – it’ll be saved away, ready to be executed as soon as a new User is created. In this case, break no longer makes sense – there’s no loop to break out of. return generally also doesn’t make sense in this case, as it may try to return to a function that has already returned. For more details on this see my question on Stack Overflow. This is where lambdas come to the rescue. A lambda in Ruby works much more like a Ruby method or a JavaScript function: return just leaves the lambda; it doesn’t try to exit the containing method.

So why use a block as a callback? Probably the best reason is that Ruby makes blocks so easy, so it’s simpler just to pass a block to the before_create method than to create a lambda and pass that (the before_create internals will be simpler as well).

Pros and cons

As I said at the beginning, Ruby and JavaScript have taken two extremely different approaches to functions. There’s a whole different discussion about methods across the two languages as well (JavaScript uses the same function type for methods, whereas Ruby has yet another type) but I’m not going to go there. Ruby has something different for every situation, and each one is optimised for its primary use-case. This can lead to confusion but can also make code easier to read. On the other hand, in JavaScript, a function is a function is a function. Once you know how they work, it’s easy.

There’s no point arguing about which of these two approaches is better – there’s no answer to that. Some people will prefer one over the other, but I like them both. I love the way blocks in Ruby make certain kinds of functional-like programming just roll off the fingers, but I also love the way JavaScript doesn’t complicate things, and makes proper functional programming much more possible.

If you made it this far, good on ya. I didn’t mean to write such a mammoth post, but sometimes these things happen. Cheers!

Why classes are confusing in Ruby

November 8th, 2010 1 comment

I wrote before about how Object and Class are confusing in Ruby. I think I know what’s so confusing about it now.

In most other OO languages there are two concepts, objects and classes. Objects are instances of classes, and classes can be subclasses of other classes. Basically, each object or class has what could be described as a pointer. An object has a pointer to its class, and a class has a pointer to it’s superclass. In Java, where every class inherits directly or indirectly from Object, there is a clear line from each individual object to the Object class, via the object’s class and its class’s superclasses. Let’s take Bob, an employee:

      class          superclass      superclass
bob    ->    Employee    ->    Person    ->    Object

There’s a clear line from bob to Object, via bob’s class, and his class’s superclasses.

In Ruby, there’s still this line, but because classes are objects as well, there’s an extra line. There isn’t one pointer – there are two. Each class has a class and it has a superclass. That’s how you get to the point where Class is_a Object, and Object is an instance_of Class. Here’s some beautiful ascii art to illustrate:

  Class -------> Module -------> Object
    |            Class --------> Module -------> Object
    |              ^
    |              |
  Class -------> Module -------> Object
    |            Class --------> Module -------> Object
    |              ^
    |              |
Employee ------> Person -------> Object

Every vertical pointer describes an instance_of relationship. Every horizontal pointer describes an is_a relationship. I haven’t drawn all the instance_of relationships of the classes, because if I did I’d be drawing an infinite tree of Class, Module and Object nodes, and I don’t have time tonight to do that.

That’s what makes Object and Class so confusing in Ruby. In most other OO languages that use Object as the overall base class, there is a straight line between an object and Object (with multiple inheritance you can get diamonds, but it all gets back to the one Object eventually). With Ruby, if you follow all the relationships you end up with an infinite tree.

Of course, this is only because I’m insisting on following all the instance_of relationships. In most circumstances you can just forget that classes are objects, and only follow the is_a relationships. The only instance_of relationships that usually matter are between non-class objects and their classes. But if you follow the rabbit hole, you’ll find just how deep it goes …

I’ve now very much clarified my thinking on Ruby classes. See: Understanding the Ruby object model.

Categories: Programming Tags: ,

Something confusing about Ruby: Object and Class

November 8th, 2010 1 comment

In Ruby, everything is an object, every object has a class, and all classes inherit from Object. Three very simple statements.

Here’s where it gets complicated:

Classes are objects

If a class is an object, then it has to have a class. That class is Class. Here’s an example

class Example; end  #an empty class
Example.class  # => Class

So, if Class is a class, what is its class?

Class.class  #=> Class

Ok, fine. What is Object‘s class?

Object.class  #=> Class

No surprises there.

So far we’ve seen that Example, Class and Object are all instances of the Class class. That’s one part of OO – objects are instances of classes. In Ruby, where everything is an object, then even classes are instances of classes. And the the class of a class is Class.

The other part of OO is inheritance. Classes inherit from other classes. I’ve already stated that everything inherits from Object (either directly or indirectly). Let’s test that:

Example.superclass  # => Object
Object.superclass   # => nil (it's not turtles all the way down)
Class.superclass    # => Module
Module.superclass   # => Object

So, every class inherits from Object except for Object, which doesn’t inherit from anything.

Where does this lead then? Well, have a gander:

Object.instance_of? Class  # => true
Class.is_a? Object  # => true

Object is an “instance” of Class, but Class “is” an Object.


Ruby really does take this “everything is an object” thing seriously. Wow. And my brain hurts.

Categories: Programming Tags: ,

Ruby post-Python: second impressions (or: how I learned to stop worrying and love the implicit)

October 17th, 2010 16 comments

So, it’s three months since I wrote Ruby post-Python: first impressions. I’ve got a few small things to say, and a few bigger things. I’ll start with the small things:

  • I was worried before about the change from elif to elsif, but it turns out this hasn’t been a problem. Having a decent case statement means I haven’t had to write a single elsif since I’ve been using Ruby.

  • The case statement is AWESOME. Being able to match against ranges, regexes etc. is just pure genius.

  • I said about parsed and unparsed strings before – at that point I didn’t know about string interpolation. More awesomeness.

  • I’m still on the fence with 0 not evaluating to false, but I can see more and more why you’d want it. For example, instead of saying if myArray.length you’d use if myArray.empty? which is obviously more readable.

  • Question marks in method names are brilliant. I first came across the idea in Scheme, and I love it.

Implicitness (implicity?)

So, here’s my main second impression. It’s all to do with the implicitness of the two languages.

In Python, there’s a preference for explicitness. Indeed, line two of The Zen of Python reads:

Explicit is better than implicit.

Ruby is very different in this respect. Ruby’s syntax is full of implicitness. One good example is self in methods. Every method in Python needs self as its first argument (I know it’s only called self by convention). And when you call a method inside an object, you call it on self. In Ruby, the self is implicit, both as an argument and as the receiver of the method call.

I’m not going to get into an argument here about which is better. My current thinking is that requiring self as an argument to every method is completely redundant, but I quite like the clarity of using self as the receiver of all internal method calls. It still makes me nervous not prepending self. to method calls in Ruby – they look like global function calls to me. I’m getting used to it though.

Another example is method invocations. In Python, you need the parentheses. In Ruby you don’t. This gives an advantage to both languages. On the Python side, it means that myObj.meth returns the method, whereas myObj.meth() returns whatever meth() returns. That gives handy functional expressivity. I use this all the time in JavaScript, where it’s essential to know the difference between func and func().

On the Ruby side, the ability to call methods without parentheses has some really nice consequences. Coupled with method_missing, it gives the ability to write really nice internal DSLs. And because direct access to object attributes is impossible, you’re able to write code that looks like direct attribute access with all the benefits of accessor methods. That is a huge win for me. Nobody likes having millions of getters and setters, but if the alternative is having to rewrite all your client code when you realise you need to do more than simple assignment they’re a necessary evil. Thanks Ruby for helping me avoid that!

Something else that’s nice with Ruby’s implicitness is the fact that arrays and hashes don’t need brackets and braces. I mean, what else could :a => 5 be other than a hash? The syntax is unambiguous, so there’s no need to insist.

Special cases

Here’s another line from The Zen of Python:

Special cases aren’t special enough to break the rules.

It strikes me that this is another big philosophical difference between the two languages. In Python, whatever you’re doing, you’d better be doing it consistently and by the rules. It’s rare that special syntax is added to do something that could be achieved with normal code. Ruby, on the other hand, tends to optimise for the common usage, which might mean in certain cases a different syntax may be needed. Eli Bendersky, in his excellent blog explained this philosophy in his description of Ruby’s blocks:

… there is one common case that stands high above all other cases passing a single block of code to a method that makes something useful out of it, for example iteration. And as a very talented designer, Matz decided that it is worthwhile to emphasize this special case, and make it both simpler and more efficient.

Is it worth keeping all syntax consistent, or is it OK to introduce special forms for certain common circumstances? Before I started using Ruby, I was probably in the former camp, but I’ve been convinced of the advantages of the latter now.


Every time the question of differences between Ruby and Python come up (or more often, the issue of superiority), the Pythonistas insist that all the metaprogramming magic possible in Ruby is possible in Python as well. But the fact of the matter is, it’s just not used that often in Python. With Ruby though, metaprogramming is just what’s done. In a lot of ways, this goes back to the implicit/explicit divide, in the sense that dynamically created methods aren’t visible in your source code. Personally, I don’t see the problem with that, but I can see why this would upset others.

What does Python have?

It’s obvious that I’ve fallen for Ruby, and Python’s lost its shine a bit for me. But it’s worth acknowledging the bits that Python does well. Interestingly, these all seem to be related more to the community than the language (although the language selects for the community pretty heavily I guess).

  • Solid libraries, especially NumPy/SciPy. There’s not really an equivalent in Ruby.

  • Stable libraries. In Ruby, and especially Rails, the best way to do something today will be the old way to do it tomorrow. There’s always a better way to do it, and it can be difficult to keep up. Because most of my experience in Ruby has been in Rails so far, it’s hard to say whether this is actually just a feature of the Rails community.

  • Mature community. This might be controversial, but it feels to me like the Python community likes to just get stuff done, whereas the Ruby community wants to be playing with the newest, shiniest things out there.

  • Decent GUI. By this, I mean PyQt. QtRuby looks like it’s miles behind PyQt, and FxRuby doesn’t look very advanced. PyQt, however, is great, even if there is a bit of impedance mismatch between a C++ framework and Python.

Categories: Programming Tags: , ,

Nike: all your runs are belong to us

August 3rd, 2010 2 comments

I like to run, and I like tech, so obviously I like to measure and graph my runs. So I use Nike+. Unfortunately, Nike+ has a rubbish pure-flash website (rant: do people still make pure-flash sites? This is 2010!).

I want a way to get to my run data without having to use Nike’s website, so I’ve decided to code something up. I’m learning Rails at the moment, so I’ve decided to do this as a Rails app. In this post, and probably some subsequent posts, I’ll be showing my progress.

Step 1: getting the data

First off, we need some way of getting the data from Nike. This post on shows how to get the raw run data through Nike’s public API. The two URLs we’ll be using are this one for getting a summary of all runs:{user_id}

and this one for getting the details of a single run:{run_id}&userID=#{user_id}

The all runs XML looks like this:

  <runList endIndex="-1" startIndex="0">
    <run id="1752070113" workoutType="standard">

Step 2: read the data

I’m doing the following in a Rails model called Run. The underlying table has fields for the necessary run attributes. I’m not going to go into this in detail because this isn’t a Rails tutorial.

require 'open-uri'
require 'rexml/document'


attributes = {
 #:attr         #xml tagname
  :distance   => "distance",
  :start_time => "startTime",
  :duration   => "duration",
  :calories   => "calories"

open(all_runs_url) do |f|  #open the XML file using the open-uri library
  doc =  #create a new REXML object
  doc.elements.each("plusService/runList/run") do |run_info|  #iterate over 'run' elements
    run_id = run_info.attributes["id"]  #get the Nike id of the run
    run = find_or_initialize_by_run_id(run_id)  #get a new Run object, either from an existing record
                                                #in the database or create a new one

    attributes.each do |key, value|  #iterate through attributes hash, which maps object attrs to XML tags
      run.write_attribute(key, run_info.elements[value].text)

    run.calculate_avg_pace  #work out the average pace

calculate_avg_pace looks like this:

def calculate_avg_pace
  self.avg_pace = duration_in_minutes / distance_in_miles

and uses the following virtual attributes:

def duration_in_minutes
  duration / (60.0 * 1000)

def distance_in_miles
  distance * 0.62

At some point I’ll refactor so miles/km is an option, but for now I just want to get something working. So far though, so good:

First run listing

First run listing

Next steps will be to make the numbers look a bit nicer, for example by showing average pace in mm:ss. Other than that, who knows?


Categories: Programming Tags: , ,

Ruby post-Python: first impressions

July 16th, 2010 8 comments

I’ve been using Python for a while and really like it. I’d heard a lot of good stuff about Ruby so decided to have a go to see what all the fuss was about. The list of differences between Python and Ruby on was useful in writing this post. Here are my first impressions:

  • One of the things that always bugged me about Python is its lack of proper lambdas. Sure, you can use a locally defined function instead, but it doesn’t give you the kind of fluency you can achieve programming in Scheme or JavaScript, say. I haven’t done much Ruby yet, but it seems there are various ways to do lambdas/closure, in a more flexible way than Python. This wouldn’t have mattered to me, but since I’ve been working through SICP and using JavaScript more, I’ve been thinking in closures.

  • This doesn’t really set it apart from Python, but it does seem to have good consistent coding conventions, which I think are important for a language. And I like the fact that capitalised class names and lowercase variables are enforced by the language.

  • I used to think it sounded dangerous, but I like the fact that parentheses are optional for function calls. I can see how this can make Ruby a very expressive language.

  • I’ve never understood why in Python objects have a __len__() method, but the standard way is to use the len() function to access it. Why not treat objects like objects and use method calls?

  • One type of array, not lists and tuples. Minor headache resolved!

  • Parsed and unparsed strings like in PHP, making use of the distinction between single and double quotes. Useful.

  • Private methods – thank you!

  • 0 as a truthy value – not sure about this. Although I suppose it’s clearer to say if count > 0 rather than if count.

  • elsif instead of elif. That’s going to cause me a lot of typos.

Categories: Programming Tags: , ,