Archive

Archive for January, 2011

Ruby vs JavaScript: functions, Procs, blocks and lambdas

January 15th, 2011 91 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

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.)

Blocks

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)
    end
  end
end

array = [1, 2, 3, 4]

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

Procs

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 Proc.new. 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 => Proc.new { |order| order.paid_with_card? }
end

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.name = user.login.capitalize if user.name.blank?
  end
end

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

Lambdas

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

lambda { |x| x ** 3 }

Both lambda and Proc.new 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
end

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

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

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++) {
    console.log(arr[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) { 
    console.log(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
end

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

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
    end
  end
end

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) {
    console.log(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.name = user.login.capitalize
  end
end

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!

2011

January 5th, 2011 28 comments

Ok, I’m going to write one of those self-indulgent “what am I going to do with the next year?” posts. If you don’t like the sound of that then I won’t be offended.

I’m working full-time for a publishing project management company based in Stroud, which is where I’ve been since I graduated in 2007. It was never my plan to stay there forever, but I didn’t know what I wanted to do instead. Then I discovered programming, and found that not only did I really enjoy it, but I was actually quite good at it. I agreed with my employer that I would work until the end of 2011, and from that point on I would become a professional software developer/web developer/programmer/whatever.

So, here I am at the beginning of 2011, and I’ve got exactly a year to establish myself as someone who knows what they’re doing and people will pay to code stuff. I don’t currently know whether I want to be freelance or employed – I’ll see how it goes. There are certain things I want to achieve this year, and I’m hoping putting them in writing will help focus my mind.

Finish SICP

I’ve been trying to read Structure and Interpretation of Computer Programs for over a year, but other things have always come up to get in the way. This year I’d really like to finish it. I don’t have a computer science background, and I don’t want to be at a disadvantage to those who do, so this is my first step towards that goal. It won’t make me a computer scientist, but it will help me to understand things at a deeper level.

Get a decent online portfolio

I’d like to create a solid portfolio to show to potential clients/employers. That includes websites/apps/games, screenshots and downloads of desktop applications, and a lot of decent (and forked) Github projects.

Keep blogging

I started this blog a year ago. My first post with any significant views was in August, and since then I’ve had a fairly steady trickle of visitors with the odd spike when Reddit likes my posts. I want to get into a regular posting schedule, so that’s another aim. I’d really like to get to the stage where I have some posts saved up ready for future posting, but we’ll see.

Get some more freelance work

I was really lucky to pick up a bit of freelance work through Twitter towards the end of 2010 which slots well into my free time, pays well, and working on what could turn out to be a fairly significant project (the NDA means I can’t go further :S). I’d like some more of that for a range of clients so I have some security for 2012. As my spare time is the only time I have for learning new things and doing freelance work, I need to find a sensible balance between the two.

Do something good in node.js

I’m very excited by node.js. I haven’t done anything with it yet, but I really enjoy working in JavaScript, and I’ve heard a lot of good things about node. I’d like to make some node apps – hopefully enough to get to a position where people will actually pay me to do it.

Learn a functional language

At the moment I’m thinking Haskell, but I’d like to give Erlang a go as well. I want to do both, and more, but I’m very aware that a year is actually quite a short time, and I need to focus. So I’ll pick one and learn it, and see where that takes me.

Stack Overflow

I think a good Stack Overflow reputation is a useful string to the bow. At one point I wanted to be on the front page of Stack Overflow users, but the amount of rep needed per day just to stand still at that level is ridiculous. I’m currently on the 16th page, and I think I’d like to get to somewhere in the top 10 pages. I think any higher than that just takes too much time to maintain (and I’ve got other things I need to spend my time on – see above).

Nick Morgan, not just Skilldrick

I’ve been known online as Skilldrick for over a decade. For a long time I didn’t want to make it easy for people to associate my online identity with my real-life identity – the web was a lot more anonymous back then. Now I’d like potential employers to be able to find me online by my name, not my handle. Unfortunately there isn’t any mention of me on Google for pages and pages. So I’d like to get my real name out there a bit more.

Categories: Miscellaneous Tags: