On: Ask HN: Why Python over Ruby?

[tdavis]

To claim that Ruby is a tangled soup of options and syntactic sugar is to miss the point really.

What is the point? I sincerely wish to learn, for my own intellectual curiosity. Because I have read Ruby code and I have done Ruby tutorials and talked to people who use Ruby and for the life of me, no matter how hard I meditate on the issue, I cannot understand why anyone would use Ruby over Python.

I don't feel Python is absolutely better than Ruby, anymore than an apple can be absolutely better than an orange, but I have yet to gain a comprehension of how Ruby is even relatively better. From a Python -> Ruby perspective I find it particularly perplexing.

Ruby presented far more cognitive hurdles for me because it allows you to do things in ways that seem simultaneously mildly more convenient and completely counter-intuitive to everything I've experienced with similar styles of languages over the past 10 years.

[greggraham → tdavis]

I currently use Python and Django for the following reasons: 1) Coworker familiar with Python 2) I had an easier time understanding the mechanics of Django than I did Rails 3) Some libraries I needed were only in Python

However, from a language point of view, I have a slight preference towards Ruby. Here are some things I like: 1) More consistent commitment to object paradigm, e.g. all function calls are actually method calls on an object. In Python, everything is an object, but sometimes you use methods, and sometimes you don't, e.g. list.pop() vs. len(list). 2) I think blocks are very handy. 3) I like the more Perlish regex syntax. 4) There is a cleverness to Ruby that might not be the best thing for a corporate environment, but it makes it fun.

So, if I was writing code just for myself, I might choose Ruby over Python, assuming performance and library support were sufficient.

[ubernostrum → greggraham]

Humor me for a moment, because I've been asking this question of many people for a long time and have never yet gotten a straight answer.

Why is len() always the thing people pick on? Why is it always "Python uses len(obj) instead of obj.len()", and never "Python uses str(obj) instead of obj.str()", or any of the various polymorphic built-ins like sum()? I've seen this so many times now that I'm honestly quite curious about it.

Also:

"More consistent commitment to object paradigm, e.g. all function calls are actually method calls on an object."

Every function call in Python is always an invocation of a method on an object, even if it doesn't look like it. len(), of course, delegates to a method on the object. But even standalone functions are method calls. Try this:

>>> def add(x, y):

... return x + y

...

>>> add(3, 5)

8

>>> import types

>>> types.FunctionType.__call__(add, 3, 5)

8

The last couple lines there are what's really going on when you call the function.

(also, just as Ruby's "built-in" functions are really methods on Kernel which is made available globally, Python's "built-in" functions really exist in a module that's made available globally (and __builtins__ is its name)

[bendotc → ubernostrum]

I'm starting to feel like a broken record here, but whenever anyone wants to pick in "str" I find myself compelled to point out:

  >>> type(str)
  <type 'type'>

That is to say, str isn't a magical function, it's a type, and "str()" is how you call that type's constructor. How is this not somehow object oriented?

Of course, even if str was a function and not a constructor, it would be an object factory which delegates to its argument via a well defined interface (the __str__ method). OOP doesn't have to mean everything-is-an-object.

[earthboundkid → ubernostrum]

Even without going to the trouble of importing types, every Python callable has an __call__ method. Including the __call__ method:

    >>> def f():
    ...  print("Helllo __call__")
    ... 
    >>> f.__call__.__call__.__call__.__call__()
    Helllo __call__

Don't use this in real life though, there's a performance penalty.

[ubernostrum → earthboundkid]

Of course, there's also the singleton that always returns itself:

  >>> recursive = lambda: recursive

[seanodonnell → greggraham]

len(list) is actually a shortcut for calling list.__len__() , any object that implements the __len__ method is therefore compatible with it. So in practice, len is in fact a method call. Almost every python function that operates on objects is just a similar shorthand.

[jamesbritt → tdavis]

"Ruby presented far more cognitive hurdles for me because it allows you to do things in ways that seem simultaneously mildly more convenient and completely counter-intuitive to everything I've experienced with similar styles of languages over the past 10 years."

Don't use Ruby.

If it presents that much trouble, go find another language. Use Python or C# or Haskell or whatever fits best and gets the job done.

Many of the things you find to be cognitive hurdles and completely counter-intuitive are there on purpose. They are never going away because many other people (and matz in particular) find them to be cognitive enhancements and completely intuitive.

Don't waste time fighting it.

[pwang → tdavis]

Ditto. The syntax seems cluttered more cluttered with sigils (some optional), and much of it seems merely to support things that Python does much more readably.

I occasionally tangle with a friend who is a Ruby fan, and who tried Python back in the 1.4 or 1.5 days and gave up on it. He still hasn't delivered me any solid reasons for trying out Ruby.

It is entirely possible that neither language presents sufficient relatively advantage compared to the other to persuade an expert in either to switch. The only exception would be due to a 3rd party application or library that is only available in one of the languages. (For instance, I work heavily with numpy and scipy; I'm not aware of Ruby equivalents.)

[artsrc → pwang]

Many people use Ruby because of Rails.

[halostatue → tdavis]

Python presented me with one insurmountable cognitive hurdle, and that's what drove me to Ruby: whitespace scoping. That single misfeature in Python is enough to keep me from ever using it in my own projects.

The compiler/interpreter should work for me, not force me to work for the compiler/interpreter. (And no, there's not always preferably one way to do things, which is an attitude I can't stand.)

[moe → halostatue]

That's an ancient argument, about as old as the python language itself. The standard rebuttal for your particular argument would be:

You indent your code anyways, in any language. Hence there is no extra work involved for writing Python.

And yes, in this case that is the preferable way to do it. Unless you want to argue for non-indented or randomly indented code.

[halostatue → moe]

It's not an argument: it's why I don't use Python. No argument here, and nothing anyone says will convince me that the Python way is the right way at all.

And yes, I can easily argue for non-indented code for certain circumstances (print-debugging outdented so that it's more obvious to the eye when you're cleaning up the binary search prints that are surrounding your bug). Python doesn't allow those circumstances; it also doesn't easily allow for nicely embedded Python in templates.

There are definitely cases where indentation as syntax is the wrong choice, and my use cases tend to hit those. Thus, I don't use Python. If someone else find this misfeature to be a security blanket? More power to them. But not me.