The blog of Rahoul Baruah from 3hv Ltd

What's going on?

My name is Rahoul Baruah (aka Baz) and I'm a software developer in Leeds (England).

This is a log of things I've discovered while writing software in Ruby on Rails. In other words, geek stuff.

However, I've decided to put this blog on ice - I would ask you to check out my business blog here (or subscribe here).

30 December, 2007

Coding in English

I've been programming computers, professionally, for over eleven years now (and programming in general for over twenty). In that time, I've tried a number of different programming environments and languages.

Delphi (Object Pascal),
Java (upto 1.4),
Smalltalk,
Ruby,
Python

and

C#,
Visual J++,
VBScript/Visual Basic,
Realbasic

as well as

Ansi C,
C++ (Borland C++ Builder, Visual C++, Ansi C++),
Objective-C (only a little bit),
PHP,
Lisp (at least some variant of it that was designed by someone at my university),
x86 assembler.

The languages and environments I like are in the first group, the ones I dislike in the latter group and the middle group are "almost but not quite". The question is what do they have in common?

Simple: it is easy to make them read and write like English.

Yeah, it's a bit subjective.

You could argue that Java and C# belong in the same group (I'll get to that in a bit). But the last group are quite happy chucking weird syntactic pieces into the mix - it makes my head hurt trying to remember when you need a & and when you need a * in the C languages. I have to say that Ruby, at first, put me off with its @s and @@s.

What about Java and C#? It has to be said that syntactically they are both very clean. But why is Java in the "good" group and C# in the "maybe" group? Because when I met Java it was cleaner than everything except Smalltalk. But when I met C# my frustration with static typing had boiled over. By the same token, Delphi now belongs in the "maybes" whereas, at the time, it was firmly in the "goods".

But, overall, Ruby wins. Code like:


dave.punch george unless george.is_hard?
(I'll never tire of that example).

Or:

using :lame do
encode '/my/audio/file'
end
(a real bit of code that only executes the block if the given the 'lame' command is present within $PATH)

Or:

hit nail, :with => hammer, :on => head, :at => :maximum_force

The latter is a pattern I often follow - using Ruby's hash as a way of building named parameters. This is something I learnt from Smalltalk, which was originally intended to be usable by seven year olds (hit: theNail :on theHead :at #maximumForce.). This makes the method definition look something like:

def hit object, options = {}
using = options[:with] || my_default_implement
where = options[:on] || my_default_area
force = options[:at] || my_default_force
... some code ...
end

The key thing here is that the options keys do not match the actual variable names because they serve different purposes. The options keys are for the users of the method, the variable names for the implementors.

Likewise, Ruby's arrays combined with blocks give you a whole load of power in a very small amount of text.

Given the choice of using Array#inject or writing something more verbose I will always go with the verbose.


collection.inject(0) { | sum, obj | sum += obj.details.size }

versus:

total = 0
collection.each do | item |
total += item.details.size
end
return total


(OK - not the best example). But, to me, the intention of the second version is immediately apparent whereas the first takes a second of squinting to figure out.

I was recently presented with something looking something like this:

sort{|a, b| index.collect{|i| (a[i] || 0) <=> (b[i] || 0))}.compact[0] || 0}

With apologies to the author, I'm still not sure what that does.


Readability is everything. Code spends longer in maintenance than development. And choosing your tools correctly can mean that, with minimal effort, your code can look like English.

No comments:

eXTReMe Tracker