Let’s talk about Python and Ruby
As a result of various things I’ve been reading up on recently, I’ve been exposed to far too many Python vs. Ruby flamewars. As someone who’s used both languages (though I’ve got much more experience with Python, and a Python-based framework is now how I make my living), I think they both solve similar problems in slightly different syntactical ways, and are pretty much equivalent on functionality.
But the debates, when they happen, always seem to come down to a few tired old arguments that just don’t hold up.
Ruby people say:
- “We’ve got blocks and you don’t.” Which seems like a compelling argument until you realize that blocks in most cases are a roundabout way of having first-class functions you can pass around, and that Python’s got first-class functions you can pass around.
“You’re not really OO because you have to use
self.” Which, frankly, I’ve never understood. Using
selfdoesn’t magically do away with objects, classes, inheritance, etc., and
selfmakes syntactic sense both in terms of implementing Python and in terms of Python’s “explicit is better than implicit” philosophy (since it makes scoping explicit). Plus, well, Ruby’s got the @ and @@ on variables.
“Blah blah whitespace.” To which Python people generally reply, “blah blah
Python people say:
- “We’ve got multiple inheritance and you don’t.” Which seems like a compelling argument until you realize that mixins are good enough for most cases.
- “You’re too much like Perl.” Which is just ad hominem. I’ve been guilty of this one in varying contexts.
- “We’re consistent and you’re not; look at all those redundant methods and multiple syntaxes!” Which is a philosophical difference that’s neither here nor there. Different philosophies work for different people.
So I’d like to have an honest talk about Python vs. Ruby. From where I sit, there are two things about Ruby that don’t have to do with syntax or ad hominem attacks or whatever that, were I coming fresh to the choice today, would lead me to Python over Ruby:
- Mutable built-in types, which are problematic for two reasons. One is that using them absolutely destroys the portability of a piece of code and makes it not Play Nice with any other components you happen to be using. The other is that it feels like the wrong solution: you’ve got an OO language, so when you want something that behaves like one of the built-ins most of the time but has this or that or the other extra thing, why not subclass it?
- Just mentioning a method’s name calls it. This makes it extremely cumbersome to really do higher-order programming, and can be counterintuitive and confusing. Let me talk about the method, pass it around, bind it to other names, and not actually call it until I’m good and ready.
I’d love to talk, in a civilized fashion, with a Ruby user about these issues and hear a Ruby user’s genuine points for preferring it over Python. Any takers?