What's better about Ruby than Python? - comp.lang.python

The title made me nervous that this would be run-of-the-mill fanboy garbage. But I trust the author (Alex Martelli), so I read it, and I'm glad I did. It's reasonable and sane.

My two big take-away points:

1) It's very nearly a wash. Ruby and Python are so close together (beneath any superficial differences) that distinguishing is almost an exercise in futility.

2) The key thing about Ruby he doesn't like is its "TOTAL, unbridled "dynamicity", including the ability to "reopen" any existing class, including all built-in ones, and change its behavior at run-time." To M's way of thinking, this makes Ruby less "suited for use in large production applications" and more suited for "tinkering."

I don't buy the argument myself, but I will admit that when I first started learning about Ruby, everything I read went on and on about how cool it was that you could open everything up and play. But as I read more, I discovered that the community seems pretty heavily tilted against monkey-patching now. (I may be wrong about this, but it's my impression.) I don't think that means Ruby is for tinkering only, but it does suggest that Martelli's concern is legitimate.

He also offers some nice pasta recipes along the way. (So much so, that now I'm hungry.)

The fact that anyone at any point can monkey patch any built-in is a potential liability for large teams, with average programmers. It must be addressed by culture and code review that you may or may not have.

Still worth it though :)

My biggest beef when I've done a little Python has been inconsistency, such as that over functions versus methods. Ruby has a simpler mental model to me. I hear this has improved in Python 3.0, but it felt bleurgh to use functions like len(str) some of the time and methods at other times (though str.__len__() is a poor workaround here). That said, the reasons have been discussed and defended numerous times, so it's definitely just my opinion rather than a critique of the language: http://mail.python.org/pipermail/python-dev/2008-January/076...

This is good stuff, except that he seems to misunderstand the ()-less method call in Ruby. There's no "function" or "object" being "called" with that syntax, as in Pascal or Visual Basic (his chosen analogies). There are no functions in Ruby in that sense, and callable objects are explicitly called (with a "call" method). The expression "foo" in Ruby evaluates to the value of the local variable "foo" if any, or else sends the message "foo" to self and evaluates to the result. So yes, the parentheses are optional, but the ambiguity is with local variables, not with any other form of function call--so the ambiguity is hardly noticeable.

Also, the parentheses are always optional, not just for zero-argument calls, so he also missed the opportunity to discuss "poetry mode Ruby": a bunch of method calls with no parentheses. Stylistically, "poetry mode" enables the pseudo-DSL style that Ruby frameworks use frequently, but can't really be done in Python.

It's to be noted that while Ruby CAN change builtin functions, the metaprogramming ability is much more often used in cases like ActiveRecord, where you can say `acts_as_list`, and it reopens the AR class and inserts new list-related functionality. It's more powerful than simply using modules, since it can make decisions as it's being included.

Working with Ruby on a day-to-day-basis, I have never reopened core classes and changed anything. Rails comes with some common extensions which simply add new methods, which are less error prone (although I avoid Rails & ActiveSupport whenever possible).