Archive for October, 2010

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: , ,

JavaScript and jQuery for programmers

October 1st, 2010 7 comments

I’ve been thinking a bit about JavaScript and jQuery. To some, jQuery is the spawn of the devil – to others it’s the greatest thing since sliced bread, and possibly better. A lot of JavaScript developers hold a lot of hostility towards jQuery, which I don’t fully understand.

The other issue is whether to learn jQuery without learning JavaScript first. Received wisdom is that this is a Bad Thing® – you should learn the basics before you come to rely too much on a framework.

In the interests of avoiding religion, I’m going to suggest a middle way. I think it’s possible to learn JavaScript through jQuery. And I mean properly know JavaScript – understand what it’s doing – not just learn the syntax for an event handler.

In these posts I want to teach JavaScript through jQuery idioms. By that, I mean I’m going to show some common jQuery idioms and explain what they mean in JavaScript. Teaching JavaScript is going to be the primary purpose – learning jQuery will come for free on top. I’ll be assuming some prior programming experience (that’s why I wrote “for programmers” in the title). The main reason for that is because I really can’t be bothered to explain assignment.

jQuery sucks ass man

Some will say that jQuery hides too much of what JavaScript does, and you should learn the JavaScript way before the jQuery way. I partially agree with that, but I think it’s important to remember one thing: JavaScript is not the DOM. For those that only read code:

JavaScript != DOM;

JavaScript is a programming language. The DOM is the API for interacting with web pages. JavaScript interacts with the DOM API. Unfortunately, the DOM is really messy. It’s also not the same on all browsers, which means any code for interacting with the DOM will be littered with if and else statements.

JavaScript, on the other hand, is a beautiful programming language. It doesn’t deserve to be dirtied with all that DOM crap. I don’t think there’s much point in learning how to use the DOM directly, as it’s a messy, incomplete, inconsistent interface. It brings nothing but pain, and the more people I can save from ever having to deal with it, the better.

A brief (and partially fabricated) history of JavaScript

Old Skool JavaScript

Back in the day, selecting HTML objects with JavaScript wasn’t necessary. If you wanted a link to open a popup when you clicked on it, you’d just add it in in the HTML:

<a href="#" onclick="popup()">Annoy me!</a>

Here’s a real life example.

Nu Skool JavaScript

One day, a Real Programmer came into the world of web developers. And he spake thus:

Thou shalt not allow the mixing of content and behaviour. Thou shalt write semantic HTML. Above all, thou shalt avoid code duplication, lest a plague of locusts be cast upon your land!

The web developers were given two years to adopt web standards. And adopt them they did. By the end of those two years, there was a new world-wide web.

To avoid duplication and the mixing of content and behaviour, the inline JavaScript in HTML had to go. But selecting DOM elements was tricky – nobody likes to type getElementById more than twice a day, but some developers were writing it ten or twenty times before lunch! Something had to give.

Out of the shadows came a man by the name of Resig. This Resig man saw getElementById and saw that it was bad. He saw CSS selectors and was impressed by their succinct clarity. And he said:

Every .man, .woman and :nth-child should be able to select their elements with CSS selectors!

and jQuery was born.

Back to the truth, back to reality

Back to the here and now yeah. Yeah, anyway. The point I was trying to get at was that JavaScript is a language, the DOM is a badly designed API, and jQuery is a wrapper around that API. That’s all. It’s not a replacement for JavaScript. Personally, I think it complements JavaScript really nicely most of the time. So if you’re going to learn JavaScript, and you’re going to want to interact with web pages, you might as well learn jQuery at the same time.

Why jQuery? Why not another library?

Yes, I knew you’d ask that. Well, here’s my rationale. jQuery won. That’s it. jQuery has a huge community, with a lot of experts. More and more are moving to jQuery every day. Even in Rails, where for ages Prototype was bundled by default, there’s been a huge push towards using jQuery. I’m not saying it’s the best. But it’s got the best support. And it’s probably going to be the most developed for the foreseeable future.

Lesson plan

I’m going to assume that you’ve got this far, seeing as you’re reading this. Hopefully that means that you’re at least vaguely interested in learning JavaScript through jQuery. Below is a list of likely topics I’ll end up talking about. I reserve the right to edit this list, reorder it, remove items and generally monkey about with it.

  • Part 1: Anonymous functions
  • Part 2: Object literals
  • Part 3: Evented programming model
  • Part 4: Closures