Ask HN: Why Python over Ruby?

Ruby has method aliases. Python does not allow a string to capitalize itself.

Ruby uses Ruby methods within Ruby classes to extend Ruby. Python has decorators so you can write functions that return functions that return functions to create a new function.

Ruby has strict object-oriented encapsulation. Python is laid-back about objects, because you probably know what's going on inside them anyway.

Ruby lets you leave off parentheses so you don't miss objects having attributes too much. Python will let you mix tabs and spaces for indentation, but passive-aggressively mess up your scoping as punishment.

Ruby has seven kinds of closures. Python has one, in the unlikely case a list comprehension won't do.

Ruby's C implementation is a mess of support for language-level flexibility. Python's C implementation is so clean you get the unsettling thought that you could probably write Python using C macros.

Ruby supports metaprogramming for cases when programmers find it more descriptive. Python supports metaprogramming for cases when programmers find it necessary.

Ruby is expressive. Python is direct.

Ruby is English. Python is Esperanto.

Ruby is verse. Python is prose.

Ruby is beautiful. Python is useful.

I like Python, but coming to it after using Ruby for seven years, well, I think it's like dog people and cat people. You can like having one species around, but you're always thinking -- why they can't be more like the other?

* Namespaces - Ruby has namespaces but when you are reading some code it is very hard to figure out what got mixed into what. This may be more predominant in the Rails world than others. You can exactly know where each one of the classes and methods came from unless you are doing a 'from x import '

Clean code - I know that with most editors today, you can have clean code. But python's insistence on indentation makes the code appear clean and very readable. This was an excellent design decision.

* Method and class invocations need () - This view is very subjective. While ruby's method invocation style gives rise to a lot of DSLs, python's style of invocation means that there are no silly Proc objects. If you need to pass a function to another function just send its name. I am not saying that one way is better than the other but I like python's explicitness here.

* OpenStruct by default - This is one of the best design decisions ever. Python uses a very fast implementation of dict for its objects. That means you almost get a javascript kind of object without the clunkiness of javascript.

I am biased a little bit towards python as I learnt python first. I do love Ruby's DSLs but I have a heart for Clojure too, in this regard. And I am actually quite happy that Jython 2.5 has come out. I am a little disappointed that Jim jumped over to the IronPython and left Jython hanging. But thanks to him, Python is there on all the major platforms.

None of these are reasons why people choose Python over Ruby. Or why Python has become more popular. It is worth noting that Python was also mentioned a lot as a teaching tool when its popularity began ramping up, and some universities have replaced Java and Scheme with Python as an introductory language.

Python really is not appreciably better than Ruby, in my experience. Nor will i claim that Ruby is appreciably better than Python. I personally use Ruby in daily life, and used to use Python prior to discovering Ruby. Both languages support some really weird warts, inconsistencies, and baggage that they retain for the sake of backwards compatibility.

Instead they really do provide different philosophies on life. To claim that Ruby is a tangled soup of options and syntactic sugar is to miss the point really. Nor is Ruby is not trying to be all things to all people. Matz cares about one thing, and that's the ability to let programmers get work done with as few cognitive hurdles sourced from the programming language itself. Does that mean you have options? Yes. Does that mean that it would be better to only have one way to do everything? Not necessarily.