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

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.

Metaprogramming

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.