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.<p>My two big take-away points:<p>1) It's very nearly a wash. Ruby and Python are so close together (beneath any superficial differences) that distinguishing is <i>almost</i> an exercise in futility.<p>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."<p>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.<p>He also offers some nice pasta recipes along the way. (So much so, that now I'm hungry.)

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 <i>len(str)</i> some of the time and methods at other times (though <i>str.__len__()</i> 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: <a href="http://mail.python.org/pipermail/python-dev/2008-January/076612.html" rel="nofollow">http://mail.python.org/pipermail/python-dev/2008-January/076...</a>

The biggest difference between Python and Ruby is in the mindset of the developers that choose them.<p>I think of Ruby and Python as two languages standing back-to-back in the same spot, mostly unaware of each other, greeting developers who come from different directions.

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.<p>Also, the parentheses are <i>always</i> 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.

What struck me the most was when he spoke about Java possibly borrowing string immutability from Python and then the realization that Python is an older language than Java.

There are two things that Ruby has that Python doesn't have a good syntax for. One is blocks; in Ruby, I can write:<p><pre><code> foo { |x| puts x } </code></pre> Whilst in Python, I need to write:<p><pre><code> def tmp(x): print x foo(tmp) </code></pre> It's not really very nice.<p>The other thing is that Python has no concept of context. In Ruby, I can type:<p><pre><code> foo(x) </code></pre> And it will execute foo(x) for the containing object. In Python, the closest equivalent would be:<p><pre><code> self.foo(x) </code></pre> This syntax difference may seem trivial, but it allows you to do some very interesting things to classes. For instance:<p><pre><code> class Foo def self.property(name) define_method(name) do instance_variable_get(name) end end end class Bar &#60; Foo property :x end </code></pre> Now the class Bar has a method called "x", without us needing to explicitly define it.<p>Ruby's instance_eval method extends this further, allowing you to execute a block of code in the context of any object you wish.

This is a fairly superficial difference, but Python's syntax grammar is very conventional, Ruby's isn't. Compare the grammars of Python, Ruby, and ANSI C.<p>Python: <a href="http://docs.python.org/release/2.5.2/ref/grammar.txt" rel="nofollow">http://docs.python.org/release/2.5.2/ref/grammar.txt</a><p>Ruby: <a href="http://web.njit.edu/all_topics/Prog_Lang_Docs/html/ruby/yacc.html" rel="nofollow">http://web.njit.edu/all_topics/Prog_Lang_Docs/html/ruby/yacc...</a><p>ANSI C: <a href="http://www.lysator.liu.se/c/ANSI-C-grammar-y.html" rel="nofollow">http://www.lysator.liu.se/c/ANSI-C-grammar-y.html</a><p>Python and ANSI C both have a similar organization of productions and names for statements and expressions. It's pretty easy to follow the grammar to obvious points where the language differs. What are valid unary expressions in Python and ANSI C? There's a production in each grammar that makes a convenient starting point and comparison is easy. What is a valid unary expression in Ruby? It's much less clear.<p>The Ruby grammar isn't large, so I'm sure some people prefer the way it's organized. Once you've absorbed the whole thing questions like "what's a valid unary expression?" don't matter anymore. But I think it's an interesting distinction to someone trying to decide which language to learn.

I cringed when I saw this link, because I was a regular on comp.lang.python at the time. I remember very clearly this discussion and the ensuing flame war. This was when it dawned on me that these types of discussions live <i>forever</i> on the internet. It pays to tone down your rhetoric, especially if you use your real name in the discussion. &#60;sigh&#62;, at least the link was not to the flame war in general.

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.<p>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 &#38; ActiveSupport whenever possible).

I think he's totally right about how to call methods. They just don't feel as first class as they do in JS or Lisp. I don't agree with his criticism of dynamic strings, however. The only time you want immutable strings is when you're not using them as strings. Ruby has symbols for when you need a hash key.

Ruby and Python are so similar, in fact, that I'm really surprised that there is no ongoing effort to merge them together. They could really use one another's libraries and various VM implementations, for example; even the parsers are almost identical.<p>The only things that are really "different" between Python and Ruby are topical features of the grammars of each, that mostly disappear once the code has been AST-transformed. These could likely be expressed more succinctly in terms of a simple common base grammar, and two small, modular sets of reader macros.

Basically Ruby and Python fill the same niche.<p>When two species fill a different niche in nature, they can co-exists. When they fill the same niche, it is a bitter fight for survival.

There are many small-to-medium differences between Python and Ruby, but in my experiences, no one <i>actually</i> chooses one language over the other because of these differences. When you ask someone, "Why do you prefer Ruby over Python?" or vice-versa, everyone has their favorite differences to talk about, but often, the choice is actually made before enough familiarity with both languages is established to be <i>aware</i> of those differences. Most people choose between the two based on <i>je ne sais quoi</i>, rather than an objective comparison of the differences.<p>More succinctly: "Ugh! Python? I hate the idea of syntactic whitespace," and "Ugh! Ruby? I have the idea of using @ for instance variables," are both cursory judgments that mask deeper preferential foundations therein.

I love the cooking analogy in the middle I use them often when talking about programming!

For me, the biggest difference between Ruby and Python is that Ruby is more perlish (i.e. more hacker, one liners, clever stuff) while Python is cleaner but a bit more verbose and less clever. So in that sens, when I want to hack something, I usually go with Ruby.. but for a big project, I'd prefer Python.<p>(But these days, I'm mostly hacking with Arc :p)

Why was a seven year old post resurrected for discussion here? Does anyone still believe that Ruby, even with its unbridled dynamicity, is just for tinkerers and won't work for large teams or production quality applications?

Very interesting to read. And it raised the question in my head about immutable types. I like functional languages a lot and I like it if just everything is immutable. Also, I like C++ where I just have everything mutable. But to have both immutable types and mutables types in one language always felt very inconsistent to me. Are there good reasons for this?<p>I put this question also on Stackoverflow: <a href="http://stackoverflow.com/questions/3584945/non-technical-benefits-of-having-string-type-immutable" rel="nofollow">http://stackoverflow.com/questions/3584945/non-technical-ben...</a>

I just get a login screen.<p>+ Newspapers require me to register and login - I go somewhere else.<p>+ Commercial sites require me to register and login - I go somewhere else.<p>+ Google requires me to register and login, guess what happens.<p>I can't be bothered. I've got stuff to write, products to ship, and a life to live. It's just another article. I've saved time by not reading it, and the chances it was useful are small. Besides, skimming the comments has given me enough of the flavor that I don't really think I'm missing much that I didn't get from the comments themselves.<p>Score another one for the HN community. Thank you.

That's an easy one... In Ruby, I can do string.reverse(). Python makes me type string[::-1] to reverse a string. In a nutshell, that is why Ruby is better than Python.<p>I must admit that I use Python more than Ruby. I like both, but know Python better. I feel Ruby is more consistent though. Either is a good language!

One thing that bothered me in Python is lambda expression being limited to one line (as far as I know). Procs/lambdas in ruby can be very complex which often need.<p>But if I wrong about this, please let me know.

"Other syntax differences such as '@foo' versus 'self.foo', or the higher significance of case in Ruby vs Python"<p>...suddenly wonders if there's a language where both case and indentation are significant.

Surprised nobody has mentioned this: Python's generator expressions and list comprehensions are delicious. I'm primarily a Ruby guy, but I think Python could teach us a thing or two. :)

make sure to use the zoom button on that... (not only the page itself but the differences too)

Fun comparison of Ruby and Python. The pasta analogy was especially entertaining.

One good reason: programming style (AKA personal preference). Python is a fine language. Ruby works better for me -- but that's just me.

This is one of those articles where any discussion thread about it will lead to the sharp knives coming out between the Pythonistas and the Rubyists. The languages are so close in so many ways, and yet so different, that it is bound to happen.