Ask HN: Why Python over Ruby? | Hacker News Reader

Ask HN: Why Python over Ruby?

87 pointscostan196 comments

I would like to understand why Python is so much more popular than Ruby. Much of the software I've seen supports Python for scripting (e.g. Miro, OpenMoko, XBMC/Boxee), and people don't seem to care so much for Ruby. At the same time, people agree that Ruby is great for writing DSLs.

I don't want a flame war or religious arguments. I would like to understand what made Python win in this space. Thanks so much for commenting!

View on HN

Ruby has clever syntax. Python has pure syntax.

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?

None of these are reasons why Python is more prevalent than Ruby.

Also, i would point out that sometimes, expressiveness is useful :P

So sorry sir, but this isn't just biased, but also bordering on a troll. Bullet points like these are not justifications in themselves. They're just a list of things to try and DDoS an argument.

What is your actual point?

Sorry to see you so down-modded.

"So sorry sir, but this isn't just biased, but also bordering on a troll."

Poster is being facetious (somewhat :) ) to make a point about differences in language and community philosophies.

The semi-troll nature is pretty amusing, though. The "verse/prose" comparison is sure-fire flame-bait; I love it. I will keep that one handy ...

Python's C implementation is so clean..

just try to compile it on OpenSolaris with Sun compiler.

hint: Perl or Ruby were passed 100% tests.

That's portability. Portable and clean code are 2 different things.

And sometimes mutually exclusive.

I think it's like dog people and cat people.

Python is like being in the Netherlands. You're surprised that everything seems to work so well but at the same time something feels a bit weird.

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

    >>> "hello".capitalize()
    "Hello"

Python has decorators so you can write functions that return functions that return functions to create a new function.

Or functions that return classes, or classes that use other objects, or any possible other use for the pattern "wrap this with that and save the result"

Python will let you mix tabs and spaces for indentation, but passive-aggressively mess up your scoping as punishment.

    $ ./mixed.py
      File "mixed.py", line 3
        print "b"
                ^
    TabError: inconsistent use of tabs and spaces in indentation

I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize!

And as for indentation, I think Guido should have followed through with making tabs a syntax error, because they are part of the syntax and are fiendish sources of error. Let's just say you have this code, properly indented with spaces:

    class X:
        def visible(self):
            pass

And you open it in a non-Python-aware editor, say for Windows, which has a four-space tab length and does not convert them to spaces. You add:

        def invisible(self):
            pass

at the end of the file using your tab key. Now you have a potentially crazy-hard-to-figure-out bug.

I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize!

So the quote deals with mutability? I suppose that makes more sense, since Ruby tends to favor mutable objects. Of course, to my Python-based mind changing the definition of 'a' or 3 seems like a poor idea.

And as for indentation, I think Guido should have followed through with making tabs a syntax error

Surely you mean "making spaces a syntax error"? That would be much more sensible, since using spaces for indentation is absurd. Even better would be simply ignoring spaces, since that allows them to be used for pretty-printing and alignment without any potential ambiguity.

Also, the bug in your example will not be difficult to figure out, because Python will/should raise an exception when parsing the malformed file. Not everybody runs with -tt, but that ought to be the default behavior (and is anywhere I get to control the installation).

> Even better would be simply ignoring spaces

Oh god no. Then you could have blocks that line up visually but execute in different scopes

PEP 8 specifies 4 spaces, not 1 tab. Python people generally prefer spaces to tabs, as do I, although I agree the semantically, it's a bit weird.

Maybe you could consider a pre-commit hook which blocks /^\s* \t/ on * .py? Or if nothing else it's simple enough to grep/ack for.

I'd also recommend making indentation whitespace visible if your editor supports it - it is syntax after all. I have vim configured to colour leading spaces green, leading tabs as blue, and tabs following anything other than a tab highlighted red. Making inconsistent indentation ugly is quite effective, though sadly ineffective on other people.

Ruby is slightly newer and wasn't particularly popular in the United States until it was popularized by Rails.

Python became popular with Linux and open source developers before Ruby did, and has had slightly more time to develop a nice set of libraries to do just about anything.

May I also add that Python works very nicely on a Windows box. Ruby/Rails works on Windows, but when I used it, it hobbled around on one leg. Going to PyCon this past year, I was stunned at how many Windows laptops there were. Python itself and the Python community are really quite OS agnostic.

The online Python documentation tends to be pretty good. When I picked up Ruby a year and a half ago, and I tried to find the documentation, people generally pointed to the pickaxe book as the de facto documentation.

Yes, the pickaxe book or the class docs at ruby-doc.org

Although I've been using Ruby on windows the last few weeks with Ruby Shoes from _why(normally use for unix scripts or web-dev). It's pretty nice (although a little rough around the edges as it's under heavy developement).

When you install shoes (the latest version anyway) you get the GUI tools, ruby gems, and sqlite, and a ruby interpreter, all neatly packaged. And there is a whole load of items I havent looked at yet. It's fun.

I used to do all my Rails development on XP, with no hobbling.

Nowadays I work on Kubuntu, and maybe things have changed, but I've no bad experiences with Ruby on Windows.

It's really easy to develop portable Python applications that run equally well on *NIX, Windows and OS/X. I mount a single share on Linux, Windows XP and OS.X systems and run the same Python program and have them run identically on all three systems, side-by-side. I'm not saying that you can't match that with Ruby, but for me it's a way of releasing programs concurrently for all major platforms.

I think this is a very good point!

Come to think of it, we, ruby programmers, don't really pay our dues. 1.9.1 has been out since January/February, and nobody bothered to package it for OSX, Windows, or Ubuntu.

Thanks for bringing this issue into the light.

What's clear to me reading the comments in this thread, is that there are a lot of people who like Python, and don't understand what people appreciate in Ruby.

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.

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.

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.

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.

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)

>>> import types

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

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)

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.

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

  >>> recursive = lambda: recursive

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.

"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.

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.)

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.

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.

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.)

Many people use Ruby because of Rails.

Python is far more mature, isn't a strange ad-hoc combination of other languages, has a third-party library to do anything and everything (which is probably also reasonably mature), and doesn't have a community rife with arrogant children.

I'm generalizing to some extent, of course, but these are the things that I and other developers I know associate with Ruby (including many who's startups are built on it). I imagine as the language and community grow and mature they will shed these associations and hopefully create a language worth taking seriously. They haven't done that yet (strictly in my opinion).

"..strange ad-hoc combination.."

For instance?

...strange ad-hoc combination of other languages.

I call bullshit, sir. Ruby is objectively less strange and more consistent than Python. Some has to do with the fact that Python is older - hence has more baggage to carry. A lot of it, though, just has to do with poor/missing design choices. Specifics?

- ruby 'block' passing convention is much cleaner and more powerful than python's 'for'/iterators.

- python's global functions are stranger and more ad-hoc than Ruby's strict object-orientation.

- ruby's mixins > python's multiple inheritance

- python underscore (and double underscore) naming conventions to overcome simple language features

Don't get me wrong: i love python - but primarily because of the faster execution and larger community - not because of the language itself.

I have used both, Python more than Ruby.

Python's iterators are more usable in many situations than the Ruby block system. I can return an iterator, stick it in a variable, call another function with it that returns another iterator, and so on.

Python's classes also seem cleaner and less magical than Ruby's. For example, a method on a class is just an attribute that happens to be a method. Much more intuitive than Ruby in my opinion.

I'm also fond of Python's idea that "There should be one-- and preferably only one --obvious way to do it".

I agree that Python does have its fair share of strangeness, but that fades away with time (you don't notice it).

Everything is an object in Ruby, including the blocks. I'm not clear how you can't pass around a block -- or is it the block + iterator metadata you're talking about? I suspect that's just an experience problem, where Python promotes iterators over lambdas so lends itself to a different style of programming; I'm not sure how often you'd want/need to pass a full iterator around in Ruby.

Personally I find blocks far more intuitive than Python's iterators and generators, but that is a subjective thing.

WRT Magical Classes, I'm not a fan of everything being stored in a dict. It seems grossly under-engineered to expose the underbelly as a basic "dumb" object; at the very least, it should've been a "Class Metadata" object with attached support methods to make it easier (safer?) to inspect or update.

And lastly: there is NEVER just one way to do it!! Witness the confusion n00b's feel over the join() method: ",".join([LIST]) where the more intuitive would probably be [LIST].join(",")... but if you MUST have join() in the string module, why not support the latter as a redirect to the former?

Seriously: this sort of dogma can make certain kinds of algorithms very messy to code.

However, my biggest beef with Python is that I seem to have to write a metric buttload of boilerplate and end up with something very Java-esque... <sigh>

It might well be experience, I haven't used ruby a great deal. I wanted to do something similar to izip in Python and couldn't see a way to do that without constructing lists in Ruby.

I completely disagree with having to write lots of boilerplate and java-esque code. I've written huge amounts of Python, and seeing Java after that really made me wince. What does Python lack that makes you feel you need boilerplate?

I don't think the one-way-to-do-it thing is that dogmatic, really. It does make code nicer when you don't have to be aware of various aliased methods, and there are less ways of making identical code look different.

You can do ", ".join(x) on any x that you can do "for y in x" on. If join were a method of the list (or sequence, or iterator, ...) then it would need to be defined over and over again.

Or it would have to inherit the method from a common iterator class. Which gets to the heart of the Ruby/Python thing: In Python inheritance just isn't as stressed, since people prefer duck-typing to isinstance. On the other hand, since you can reopen classes in Ruby, it's not as crazy to use the modification of a common base class as a means of making a method work with a wide variety of object types.

Under what circumstances have you had to write a "metric buttload of boilerplate"? I've not encountered this with Python in my experience.

Ruby 1.9 has real iterators now.

They're in 1.8 now too:

    >> [1,2,3].each
    => #<Enumerable::Enumerator:0x801820f10>
    >> RUBY_VERSION
    => "1.8.7"

They've been around for awhile

    >> RUBY_VERSION
    => "1.8"
    >> require "enumerator"
    => true
    >> [1,2,3].each
    => #<Enumerable::Enumerator:0x29326940>

Quoting an article on the topic:

Having ploughed through several tutorials, I did not find Ruby particularly "elegant", or its syntax particularly obvious. Much of it seemed ad hoc, thrown together, in particular when there were several different ways of doing something, and it seemed to be the philosophy of the language to provide all of them. I did not find its constructs as intuitive and natural as claimed, trying out simple coding examples proved as frustrating when things didn’t do what you’d suppose they’d do...

(http://www.bitwisemag.com/2/What-s-Wrong-With-Ruby)

I actually gave Ruby a shot, going through the interactive tutorial on http://tryruby.hobix.com. I couldn't do it very long, however, because it was completely ridiculous. In what world does it make sense for hash keys to double as string grep? For instance:

    my_string['foo'] = 'bar'

will replace the first instance of foo in my_string with bar?! WHY?! I can stick an exclamation point on the end of method calls... to signify mutation? WHY?! What twisted logic allows one to rationalize multiplying strings like:

    "5" * 2 == "55"

yet throw an exception for:

    2 * "5"

It makes absolutely no sense! And why would an integer have a method for converting itself to a string? Or an array? I found so many things in Ruby that made me think, "Okay, superficially that's really convenient and sorta cool... but it makes no sense and it is absolutely counter-intuitive. And I feel dirty using it, even if everybody is doing it." Some people, I assume, find Ruby to be "elegant" for the same reasons I find it to be "an abomination."

Well, I can answer at least a few of those 'WHY?!'s.

Firstly starting with my_string['foo'] = 'bar', this is a syntax that is used a lot in Ruby for anytime that you wish to recover a subset of a collection - you can use it with a Dir object for example to recover a subset of directories/files, or in the case of a hash, to recover the object stored at the key. The thing is that you need to think about it as being a subset operator, rather than an index operator.

The exclamation point at the end of a method name has no syntactic meaning - it is simply a naming convention used by the standard libraries to indicate when the method mutates the object or not. Same same for method names ending with a question mark, it's just a convention to indicate that the response will be a boolean.

As for the whole "5" * 2 vs. 2 * "5", I must admit to not understanding where you're coming from. I don't see how you could expect any other kind of behaviour from an object orientated language. Personally I don't like over-riding arithmetic operators for non-number types, for precisely this reason, but hey, some people like it, so why not?

Integers converting to strings? I think every language has that no? I mean there's always something like: sprintf(myStringPtr, "%d", myInteger); or cout << myInteger;

etc etc

By making this a standard method on all classes (to_s), Ruby makes it really easy to dump a class to a serial format, which is very useful for debugging, as an example.

I get the impression that you simply didn't spend enough time with Ruby to come to understand its idioms, in which case, you're not really in a position to effectively criticise the language...

I suppose these just seem odd to me, which was my point. Not that I find something absolutely wrong about them, anymore than I can find something wrong about a language which doesn't have mutable variables or whatever the case may be.

A lot of Ruby's conventions simply scream "ambiguity" to me. A "subset of a collection" is extremely ambiguous; if there is more than 1 foo in my_string, does it always get the first? How do I get the rest? my_string['foo'][2] or something? I can't even intuitively make something up which makes sense to me. Perhaps there isn't a way to get the others, which I suppose would be in line with Python, which doesn't supply a string method to find all occurrences at once... but how do I offset it?

I can see where standardized methods like to_a can be more convenient, but they also open up the possibility for unlimited ambiguity. What does Foo.to_a do for your Foo class? It could do anything! There's no way I could rely on these methods to do something across the board unless I know your class conforms to some Interface (do Ruby folks use/have Interfaces?). In Python, if I do

  [foo]

Then foo is now a list. I always know what I'm getting. I always know what int() is going to attempt to do to an object, etc.

Perhaps there isn't a way to get the others, which I suppose would be in line with Python, which doesn't supply a string method to find all occurrences at once... but how do I offset it?

Yes, there's no way to get the other matches using [] as far as I know, it's just a generalization of being able to pass various types to it; Fixnum, Range, Regexp.. I don't see the harm in doing something with String too. If you wanted to extract multiple items, you'd use something like String#scan, or if you wanted to do a global replace, String#gsub, which can also accept a code block to perform computed replacements.

I can see where standardized methods like to_a can be more convenient, but they also open up the possibility for unlimited ambiguity. What does Foo.to_a do for your Foo class?

As of 1.9, it does this:

    NoMethodError: undefined method `to_a' for Foo:Class

In 1.8 it issues "warning: default `to_a' will be obsolete".

In Python, if I do `[foo]` Then foo is now a list.

You do the exact same thing in Ruby, though if you're wanting to cast your argument like the old to_a did, you use Array(), which won't turn [] into [[]]. If you want a number, Integer() or Float() will raise an exception if they can't give you one.

>I get the impression that you simply didn't spend enough time with Ruby to come to understand its idioms, in which case, you're not really in a position to effectively criticise the language...

Well yeah like others have been saying, python is more attractive to new users is probably partly why it's more popular. You don't need to work as hard to understand its idioms, it's more readable by newbies (by anyone), etc.

"As for the whole "5" * 2 vs. 2 * "5", I must admit to not understanding where you're coming from. I don't see how you could expect any other kind of behaviour from an object orientated language."

Python has a __rmult__ method. If you do A * B, first it internally calls A.__mult__(B) then if that raises TypeError, it tries B.__rmult__(A). It's pretty elegant, I think. For Ruby, it wouldn't look as nice to do A.r* though, I guess, but it would be a nice bit of functionality.

"5" * 2 == "55"

You're calling a method on a string, so you got the string doubled. Seems to make sense to me.

Obviously in this case the order of the arguments matter.

"Obviously in this case the order of the arguments matter."

It's not obvious in terms of intuitiveness, no. Why not extend the Integer class to know to call mystring's * method when their order is reversed? That would be intuitive.

Re: "5" 2 == "55" vs. 2 * "5" == Exception*

You need to remember that EVERYTHING is an object, there are no basic/literal types at all; in this case, "5" is really just syntactic sugar for creating a "5" String object, 2 is syntactic sugar for creating the "2" Integer (Number?) object, and the " * " operator is syntactic sugar for the " * " method of the "5" String object == ' "5".times(2) ' (which is similar to Perl's ' "5" x 2 ' construct).

The String class supports a " * " method which creates n copies of it's string value, and concat's them together into a new String object, but the Integer class does not.

Many "basic" objects have explicit conversion methods, but will also frequently support implicit conversion where it makes sense.

Why does it overload "*" on the right, but not on the left side of the string? Python has __rmult__, and it works. Please do not try to make language warts look better by spilling a bucket of architectural-astronauty crap.

Huntbach's article was pure nonsense when it was written[1], and it remains pure nonsense now.

[1] As I wrote two years ago: http://www.halostatue.ca/2007/03/17/whats-wrong-with-bitwise...

"And why would an integer have a method for converting itself to a string? Or an array?"

You know that under the covers in Python str(1) works by calling (1).__str__(), right? That's why you can make str(my_custom_class) work.

... a community rife with arrogant children

It's difficult to accept your rational argument when you include stuff like this.

Check out the Ruby blog scene. It's a wonder they actually write any code in between the bragging about how awesome they are and slagging each other off.

So you're going to judge the entire Ruby community by like... 5% of their bloggers? :P

To be fair, "Pythonista's" were renowned for slagging-off most other languages, and in the same breath, claiming how very like LISP their Python is. Hopefully this attitude has died off...

Ruby developers (Rubyons?) were renowned for typical Japanese self-effacement when it was becoming popular, which I think was some of the appeal... I guess what goes around comes around...

Hey, now we can judge the entire Python community by tdavis's comments.

shrug You certainly could! Though judging any group of people by my comments would certainly do a disservice to that group.

Why is that? It can easily be proven. I'm not trying to suggest that everyone who uses Ruby is an arrogant child as I even have friends who certainly don't fit that bill, but when you have an especially abrasive attitude like that within a community, it only takes a minority to sour the majority.

And while it certainly isn't a fault of the language, it definitely influences it usage for some people.

... it only takes a minority to sour the majority.

That's a decision you make for yourself, not an absolute truth.

I thought I was rather clear on the fact that I wasn't speaking in absolute truths. My answers reflect my personal opinion of why I (and others like me, in some cases) choose Python over Ruby.

Umm....and have you ever spent anytime time in #python? Some are helpful, but there are a choice few who I would describe as arrogant children.

In any community of size, you get good seeds and bad seeds. Python is not immune to this.

Actually, for a while I was spending quite a bit of time in #python. I didn't come across "arrogant children".

Looking at some of the drama and prima donna action in the Rails community (from a distance) just made me sad and grateful that my corner of Python (scientific computing) doesn't have those sorts of issues.

Well.. Zed Shaw is raving about Python these days.

And yes, a lot of us pythonistas view him with suspicion.

"a community rife with arrogant children."

During FISL, a couple days ago, I witnessed something that really bothered me. It was a presentation comparing Rails with Seaside (which is, by itself, like comparing racing cars with subarines) and the arrogance of the Rails guy dismissing Seaside, Squeak and Smalltalk was very uncomfortable.

It seemed the room was too small to fit all the egos inside it.

I considered staying until the end and asking a couple questions to demolish the presenter, but I decided it would not be worth it. His belief on the inherent superiority of Ruby and Rails over any other language and framework, past, present and future, bordered on the religious.

Rails folks are like that. Even though the rest of the Ruby community is much more reasonable, the weekly Rails debacle has driven a lot of people away from Ruby, including me.

If Rails weren't around, it would be much easier to enjoy Ruby without having to use it in isolation. Then again, a whole lot of people wouldn't have gotten into it in the first place.

Ruby lived fast and died young. If you don't want to use Python, learn Haskell.

"Ruby lived fast and died young."

How can you say that a language with active development and an active community has "died"? Seems like an odd conclusion to make, IMHO.

And it is really easy to enjoy Ruby without Rails. A friend and I have been doing it for a couple years now.

"Ruby lived fast and died young. "

Sweet! I am making a living using a zombie, undead, from-beyond-the-grave programming language!

I better hook up that USB Ouija board and get coding.

That's how I feel about Django at this point. A quick glance at reddit reveals how out of hand it's getting; the answer to every web programming question is "Django!" regardless of whether it's relevant or not. And every popular comment or blog post by Django developers discussing Rails contains a bunch of inaccuracies. At least with Rails there's enough of a push back that even the the annoying minority is better behaved, and Rails development these days is more wycats/merb than anything else. I've always liked Django, but in recent months I've been totally turned off of it, but these days it's tough to develop web apps with python and avoid django.

Hmmmm. Is it 'really hard' to develop web apps with python and avoid django? No. It isn't.

Well... You can use Zope and Plone. I have done so for a very long time (in fact, I started using Python because of Zope).

Zope 3.x (Plone runs on top of Zope 2.x) is a very nice application server. I wonder if it would be possible to make it work seamlessly with things like Hadoop instead of ZODB.

"Python is far more mature"

How so? It's mot like Python is 10 or 20 years older, so how do you determine the "far more" part?

And of what value would this difference in maturity be? COBOL is "far more" mature than Python. Is that a big win for COBOL?

Once a language reaches some reasonable age and general wide-spread usage, points about maturity seem silly.

(On reflection, I suspect you're just trolling.)

In programming languages, like people, maturity is a function of more than just chronological age.

Speaking as a commercial Python developer, I can honestly say that there is a tremendous amount of interest in and usage of Python across a wide spectrum of commercial and enterprise applications. This is everything from realtime high-frequency trading to oil exploration to mixing toothpaste to processing Hubble images to manufacturing SATA and PCIe driver chips. The very active, very professional community around the language, combined with the ease of integration with legacy codebases in FORTRAN, C, and C++ makes it very popular in the commercial sector. Consequently, there are numerous institutions and companies that have developers spending time on improving the langauge and its underlying libraries. Guido is a sharp guy and is sensitive to all the places where Python is used, and he takes these into consideration when approving or disallowing language changes. This understanding and the overall process makes the language "mature".

On the flip side, I am not aware of any significant impact of Ruby in commercial development that is not web-driven. When we bid on projects and talk to prospective customers, we're typically making a case against Java and C++. I can't recall a single instance where someone seriously asked us about Ruby. (We've had more inquiries about KDB and K, that abomination of a language.)

So, just my $.02 as a scientific software developer.

For me it's very simple !

I can READ other people's Python code with greater ease than Ruby, Java, C#, C++ or even C. At the end of the day, the quicker I can assimilate library code the quicker I can use it well and the quicker the module gets completed and fully tested. Of course, with Google and Eric Raymond raving about it, the confidence factor increased further.

This is a cultural issue. In the Ruby (or Perl) community, if you use obscure language features to do a common task in a single line of code, you will be worshipped as a god. In the Python (or Tcl) community, you will be viewed with suspicion. Not that Python doesn't have one-liners (e.g. comprehensions) - just that everyone agrees which ones and when and how to use them.

I've been working in Ruby for 3 years now, and i can promise you that unclear code is very much not appreciated by not only the people i work with, but all of the open source projects i'm involved with.

It is true that Ruby gives you a lot of rope. People with good design sense appreciate that your code should not be too clever.

Agreed. The ultimate goal is clarity. Everything else is subservient to it.

"This is a cultural issue. In the Ruby (or Perl) community, if you use obscure language features to do a common task in a single line of code, you will be worshipped as a god."

Just which Ruby community is this? None that I associate with, that's for sure.

To the people who voted the OP up; is it because of your own first-hand experience with other Rubyists? For all I know there are clusters of Ruby coders who encourage obscurantism, but I've not encountered them (though I've been part of debates over just what constitutes "obscure").

In Perl you have "wizards" and in Ruby you have "rockstar ninjas"... No other language communities do this.

Except for python, of course:

http://www.google.com/search?q=python+ninja

http://www.google.com/search?q=python+rockstar

You'll get that in a Perl Golf competition but the trend these days it towards much more readable and maintainable code. Which is why we have things like Moose (a better way to do objects).

Here are some stats from google on the relative use of obfuscation for perl, python and ruby:

<pre> Weighted use of Search Term Hits Search Term Hits obfuscation

"obfuscated perl" 1390 "perl programming" 164000 0.85% "obfuscated python" 234 "python programming" 157000 0.15% "obfuscated ruby" 269 "ruby programming" 133000 0.20% </pre>

If I use the word golf, I get: <pre> Weighted use of Search Term Hits Search Term Hits golf

"perl golf" 1780 "perl programming" 164000 1.09% "python golf" 171 "python programming" 157000 0.11% "ruby golf" 547 "ruby programming" 133000 0.41% </pre>

This is of ccourse, the same statistics that fueled the last financial meltdown :-)

Why language X is better of Y makes no sense. Every language has its benefits and downsides. Python has been slighly longer around and has a bigger user community which resulted in more available library code. Ruby and Python is pretty much interchangable in the sense of features as they often steal from each other and vice versa.

Ruby

- follows TIMTOWTDI

- Mutable strings etc.

- has a greater emphasis on code generation ("meta")

- VM's are much slower than Python (there is no Psycho etc.)

- emphasizes code clearity and readabiliy (human cycles are more important)

- Libraries are much less mature

- ...

The lists of differences could go on forever. A comparsion and "why" is difficult. I think they are too similar and the people are too polarized.

A language is a tool to solve a particular problem. In the case of Python you have higher momentum of the community and the switch from C/C++/Java to Python is often easier than to Ruby. (Wild statement of me with tests from a sample set of 2 test subjects ;) )

Probably the best characterization I can come up with is. Python is already on this "Enterprise" trip where companies use it a lot and so forth. Ruby has some interesting companies pushing it (Twitter etc.) but is not compeletely there yet, it still has more "hacker" and "monkeypatch" feeling. Oh wait, we call that "ninjapatching" in Ruby ;)

Code is read more than it's written - TIMTOWTDI is a double edged sword.

Speed comparisons between Ruby and Python are kind of silly. Ruby 1.9 and JRuby are (if you look at http://shootout.alioth.debian.org/u32/benchmark.php?test=all... ) comparably fast to Python, and obviously measure up slightly better against Python3.

Python is not a radically better choice in terms of speed (and hell that's true even w/ 1.8. Sure Python's faster, but we're not talking orders of magnitude here).

Also Twitter is lately moving to Scala because of Ruby's annoyances.

I prefer the design of Python over Ruby. I'd be hard pressed to explain why -- something vague about Python being straightforward yet graceful -- but that aesthetic preference is enough to sway me.

Me too, but I don't think it's just a preference. I come from a C/C++ background (I'd say the majority of people do, or C# or Java), and Python looks much more familiar and obvious to me than Ruby.

For example, this from Wikipedia:

  (3..6).each {|num| puts num }

Has some funny brackets and pipes. In Python, it's much more familiar to C-ish folks like me:

  for i in range(3, 7):
      print i

Ruby's syntax is flexible:

  for i in 3..6 do
    puts i
  end

Very flexible. Once you learn what the sytnax means the implementation of blocks and iterators is one of the best parts of the language.

    3.upto(6){ |x| puts x }

I don't think the uniqueness of a language is any reason not to learn it. To be honest that sounds lazy.

PS I'm not a Ruby zealot, and Python is a great language

So I just saw 3 ways to print from 3 to 6... are those all used in the wild?

Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

Sure, there are other ways to do it in Python, but it'd be frowned upon to use something like 3.upto(6) rather than a standard range() that everyone is used to. Readability matters.

I'd argue 3.upto(6) is much more readable and obvious than range(3, 7). Even just on a conceptual level, Python requires a degree of translation and its stop argument is not intuitive whereas even someone who has never programmed before can understand the Ruby.

http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831....

While I agree that readability matters _a lot_, the "Zen of Python" honestly bugs me. But maybe it's just the counter-culture ethos that dwells inside me. +)

Note: I used Python daily at work and for open source projects. I also use Ruby for open source projects. I like them both.

I like the Zen of Python myself, but the first thought that crossed my mind was that the Python example could use xrange and save the generation of a temporary list. So there are at least two ways of doing it in Python, both of which look very similar and differ only in the underlying implementation.

This makes me curious how much more frequently range is used than xrange and in what situations it's preferable.

This is an acknowledge minor "wart". In Python 3.0, range() does the same thing as xrange().

I'm sorry, did you say there's only one way to deal with each integer in a set of numbers? Admittedly I don't know very much about python, but it seems that at the very least you could do this recursively.

Neither Python nor Ruby AFAIK have tail-call optimization.

You're right, that's pretty C/Python-like. Nice. In fact, I've often thought that Python could make the syntax "n..m" expand to "range(n, m+1)" or equivalent.

However, Python's TOOWTDI comes to mind. Not that it's quite true, but probably closer than with Ruby. I guess one could debate whether TOOWTDI is a good thing -- but I reckon Perl is the argument as to why it is a good thing.

Speaking purely for myself, the only reason I switched from Perl to Python is I had a great deal of difficulty understanding the perl code (because I'm a poor perl scripter) I wrote after a day or so. That, and the language construct HashOfArrays and ArrayOfHashes is exceedingly difficult to do in perl without referencing a manual. The only (Edit: Alternative scripting) language really out there with mindshare in 2001 was Python. I was able to read my python code. I never had to look at a manual to implement complex data structures. As a bonus, I can type "help(command) or dir(command) within the python CLI. I've never really had the need to switch to another environment. Ruby might actually be 10x better and faster for my typical tasks than python for all I know.

From the Python website:

"Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language."

When I first saw this, I went "Google? Whoa. I gotta check this out" :)

Google, NASA, Industrial Light and Magic...

That's one cool list

"'Google? Whoa. I gotta check this out'"

I had a similar experience in '02 or '03. Then I quickly recognized that Google's decision to concentrate on Python, Java and C++ doesn't have any bearing on my companies' choices, especially since some major factors in Google's decisions (eg, dealing with a very large number of internal developers) just don't apply.

It is impressive, but beware of cargo culting.

http://en.wikipedia.org/wiki/Cargo_cult_programming http://weblog.jamisbuck.org/2008/1/7/never-ever-cargo-cult

I haven't really looked at Ruby that hard, but from my perspective as a reformed Perl user I found Python's syntax to be very clean and well organized. On the surface ruby looks more Perl-like to me, more clutter, not as easy to read as Python.

Having found Python, I really don't feel a pressing need to learn another scripting language. Instead I'm working on Objective C.

Although I'm a Python programmer, I urge you to take at least a cursory look at Ruby. It's actually very different from Perl.

Ruby borrows some stuff from Smalltalk. You know what other language borrows heavily from Smalltalk? Objective-C :)

Part of what makes the difference is cultural. It is of course possible to write very legible Perl code, but that was, at least for a time, far less visible than the "cool hack in 1 line of extremely dense code" culture, and all the "more than one way to do it!" stuff. Ruby can be messy, but there is a tendency to keep a lid on it.

I totally agree about picking the languages you want to learn. There's only so many hours in the day, and you will have different pref's on style and language design, anyway.

I'd love to learn Scala (after being a Haskell and Ruby fan for years) but finding the time is incredibly difficult...

Python is older, and gained popularity before ruby. That's why it's more established outside of the web development frameworks space.

How does python compare to ruby in terms of web development?

I get the impression that there are more 3rd-party libraries in Ruby, so it is easier to get web code up and running with ruby.

See http://pypi.python.org and convince yourself :)

See http://rubyonrails.com and convince yourself :)

Ruby On Rails is a framework not a collection of third party libraries (like pypi), that said if you really want to compare RoR to something then that's http://www.djangoproject.com/

Can't compare to ruby as I haven't used it much but the python world is seriously overflowing with web-related frameworks and libraries.

Django is the most popular single framework, but at least as many people prefer to roll their own based on various modules. Some of the most popular backbone kits would be werkzeug, cherrypy, webpy, pylons. Then there's literally dozens of template languages (jinja, genshi, cheetah, to name a few) and at least three mature ORMs (sqlalchemy, storm, sqlobject) to choose from.

So, while I have no idea about ruby libraries I can assure you that in python-land you get to choose between at least two mature options for pretty much any web-related task.

I think this impression comes from the culture of experimentation in Ruby and more widespread willingness to adopt new tools and libs very quickly. Python definitely has a diverse web development community and more options in some areas (like templates), but it's more conservative, not necessarily evolving as rapidly and, like Python overall, resists influence from other languages.

For instance, Haml and Saas are pretty widely accepted by Ruby web developers, whereas Django templates are very popular with Python web developers precisely because because they are close to straight HTML. Ruby developers (like Ruby itself) readily adopt good ideas from other languages, including Python (rack from wsgi, rip from pip, merb slices and rails engines from django apps), while anything that resembles anything from ruby or rails, like some Pylons components, gets criticized by many python developers. It's noticeable with version control, too, as svn is still very widely used by Python developers whereas Ruby and Ruby/Py developers moved completely to git and hg over a year ago.

FWIW, there are lots of Python folks moving to git and hg as well. But I don't understand what VCS choice has to do with language culture. What's next, a critique of editor choice? :)

Python is such a large tent that it's quite inaccurate to say that "the Python culture" lacks a sense of experimentation and adoption of new tools. What you might be getting at is the fact that there are already so many existing libraries in Python for doing most things that there's not a lot of public reinvention of wheels going on.

"FWIW, there are lots of Python folks moving to git and hg as well"

It's not remotely as universal as it was for Ruby developers. When working with Python you still can't go a day without hitting an svn repo, but with Ruby you'd easily not touch one for months.

"But I don't understand what VCS choice has to do with language culture."

A lot, and I already described it. Ruby developers and the Ruby language overall are less conservative and more open to dramatic change than Python developers or the language. Each model has its benefits.

"'Python is such a large tent that it's quite inaccurate to say that "the Python culture'"

It's a large tent, but the common thread is Python and Python's principles, and they define the culture.

"there are already so many existing libraries in Python for doing most things"

But individual developers don't do most things, each works on certain things. Python has lots of libraries, but that doesn't mean it's the best choice for any specific job. As a web developer, there are a huge number of Python packages that don't matter at all in that domain. If sheer number of libraries mattered, we'd all be using perl.

Personally I like generators, generator expressions and list comprehensions much more than the Ruby equivalents (chaining each/filter/etc). Python is cleaner overall, and if you want metaprogramming you can still do a lot of it. Also Python has better libraries and runs on App Engine.

I'm too big fan of iterators, they're great!

Although it's worth noting that Ruby too, runs on GAE using JVM based implementation (JRuby).

Python got popular earlier - it was already gaining significant converts in the early part of this millennium, and the later years of the last one. Ruby only really took off when Rails started to get popular. But it has really taken off, in a way that I think sometimes makes the Python guys (who have been slowly and steadily gaining ground) a bit jealous.

They're both good languages with good communities though. Each has a few advantages and disadvantages, but they're similar enough that if you know one you should probably stick with it and be happy, and pick something farther from the tree as your next language (Erlang or Scala, say).

"But it has really taken off, in a way that I think sometimes makes the Python guys (who have been slowly and steadily gaining ground) a bit jealous."

Reality seems a bit different to me:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

http://bitworking.org/news/413/ruby-books-sales-a-retrospect...

I believe it is more of a personal choice than anything else. That said, here are the reasons I like Python more than Ruby.

* 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.

For me personally, it boils down to me liking the library more, the syntax more and the common programming styles. Ruby is very hard to follow me due to the (imho) overuse of meta-programming and using language constructs that obscure the actual meaning of the program. Patching objects and being overly clever with language features makes ruby code harder to read.

It's also, to me personally, a lot faster to whip something up in Python than in Ruby, even when I knew them at about the same level.

I find ruby more intuitive. I learned python first but switched over (not due to rails, just enjoyed ruby more). It sounds like you are complaining about the meta programming in the Rails code more than any intrinsic feature of ruby the language.

I wish Ruby were good, but it's so fucked:

  Matz's decision-making process
    He tries to make Ruby be all things to all people
      Lots of confusing sugar and overloading baked in
    I much prefer Guido's hard pragmatism

  The pointless panoply of function types: Methods, Blocks, Procs, Lambdas
    All intertwined and yielding into one another.
    I love that in Python there is only one:
      Objects with a __call__ method, defined metacircularly.

  The culture of adding/overloading methods on base classes
    Many gems do this en masse, and there are a lot of low-quality gems
      Seriously, Ruby might have a ton of new gems for everything, but they
      are almost universally awful. A culture of sharing any code that *could*
      be a module, no matter how trivial, leads to immature crap being widely
      used because it was there already, with a mess of forks to clean up
      afterwards. At least most of them are test-infected...
        Python does come with a few stinkers, mostly ancient syscall wrappers.
    Especially disastrous because it's unscoped, and infects the whole process
      For a language with four scoping sigils it sure fucks up scope a lot
    The syntax practically begs you to do it, anything else would look shitty

  The Matz Ruby Implementation
    The opposite of turtles-all-the-way-down (Smalltalk crushed beneath Perl)
    It actively punishes you for taking advantage of Ruby's strengths
    The standard library is written almost entirely in C
      It doesn't use Ruby message dispatch to call other C code.
      That means that if you overload a built-in, other built-ins won't use it
    Anything fiddly that's not written in C will be dog slow

Great comment ! Reminds me of Lisp, a very simple concept that is powerful and easy to implement and then CommonLisp comes along trying to include everybody's favourite feature. As a result many people get put off without digging for the gold.

I like Ruby (culturally) more than Python.

Python has NumPy/SciPy/and friends, so I use Python.

This, I feel, is a strong point for most who are using a scripting language to do scientific work.

How do you find Numpy/Scipy on Python compared to statistical languages like R?

Also what kind of work are you doing?

I don't know about tel, but I use both pretty frequently (and usually together with rpy). R is great for some things, but I typically find that I need to use a general purpose language to acquire the data I'm processing. There are some processing steps that I easier in R though, so I offload things to that when it is more efficient. But for simpler things, I find that numpy is more than adequate for processing data that I've already got in a Python session.

I use them for bioinformatics analysis (large scale genomic comparisons and microarray data analysis). So the larger problem isn't the calculations, it's the data management. And for that Python wins over a pure R solution.

That's pretty much exactly how I feel.

I personally love R. More specifically I love how everything is implemented (at least sketchily) in it. Most specifically, I love how its plots look. If it could handle the large data sets I'm working with these days (MRI 3D+time images, sometimes multiple contrasts at once) I would use it a lot more.

So yeah, RPy is another big win for the Python side of things.

For me, it was the 'magic'. Ruby seemed to have a lot of 'magic' working behind the scenes - which confused the hell out of me when I tried to figure out how something worked a particular way. Python on the other hand has far less magic and more transparency - magic replaced with a transparent box showcasing the logic... Just made it easier for me to wrap my mind around...

One is not better than the other, and neither have "won".

In Python you dont' have to type 'end', just kidding although for some reason it reminds me of VB for this reason. I wish it didn't but it does. Why have an end be anymore than 1 character on a serious note, that is lots of keystrokes extra not needed.

But more seriously Python is a growth like Javascript. It has grown and adapted to every change it has been required because it has a very rapid iteration time and is great for wrappers to core C. It is clean and maintainable.

For this it has made huge inroads to system administration, game development, tool plugins, web development, command tasks and everything else. I have yet to have one instance where there weren't numerous libraries for every task. Even if you don't want to use a third party library there are many examples of how to do it.

Python is really at it's core many things. It is a functional language, it is an OO language and it can be procedural. It can wrap intense lower level libraries or port in a C extension for speed. The same code you wrote for your desktop api, can be used in a desktop app, a service, website, a web service, a tool plugin, at the command line or any way you need it.

It can float like a butterfly and sting like a bee.

Like Javascript, Python is based on a core few types, lists and dictionaries (objects). All the languages that seem to permeate like viruses have this basic computer science fundamental. It just is as simple and clean as you can get. Ruby also has this but it came a bit later.

And finally, it is named after the great Monty Python.

Just as a quick note, you can use '{' and '}' instead of 'do' and 'end' if you want. Standard conventions say that one line blocks get {}, and multi-line ones get do-end.

Just for blocks/procs. Method definitions still require def/end.

Not having some way to explicitly note the end of a function was actually something that initially bugged me about Python. I think I'm over it now...

end

I've worked with a lot of languages. Python, C++, Scheme (and CLISP), Java, C#, Perl, Ruby, etc. Every language I've used besides Ruby, I feel that I have to fight the language to actually implement my idea. The fact that programmers want flexibility should be obvious by the contortions present in C++ with boost, particularly the lambda libraries. People are so desperate for flexibility that they use template metaprogramming. This general impulse points to programmers wanting better abstraction capabilities. C# and Python have higher order functions and many other virtues, too. Ultimately, for me I could do anything I wanted to in Ruby without fighting the language. I'm sure there are people that have the same personal connection with Python. When I want the very flexible abstraction--I use Ruby. There are things that out of practicality I use Python and other languages for. Awhile ago I was experimenting with fractal terrain generation. The implementation is procedural, and all using Ruby does is greatly limit the performance of the program--so I implemented it in C++. I use Python for Bioinformatics research because of the excellence of Numpy.

Python has IMHO better support for GUI toolkits - Tk support in main library, PyGTK+, PyQt. And two more words about library - import antigravity :).

And strong company backing: Google has have hired some of the core Python developers, and some of its infrastructure is written in it... Flumotion with its streaming media (although codec stuff is mostly gstreamer, but most of the networking stuff is in Python)

And the final straw - Python just seems to be a bit more beginner friendly...

People should be careful how much they quote Google as their reason for preferring Python.

The main reason was when they were standardising on the core-languages they could support, Python was enormously far ahead cf. the competition, so it was an obvious choice. And now, with all that code investment, you do NOT want to start again. And if you have the money, of course you'd be interested in hiring the best developers for your code-base.

Likewise, I believe Python 3000 is unlikely to used in Google for the forseeable future, due to that same code investment. I don't think Python 2.6 is fully supported, either...

I don't think "a bit more beginner friendly" is truly accurate. Most beginners will look for doc's and books, and for a good few years, recently, there was a dearth of good Python books while there seemed to be a new Ruby or Rails book every month, including several allowing you to d/l them for free.

I have to admit that I used to recommend Python to beginners for a long time, as it helped them avoid developing bad habits with the other equally popular "beginner" PHP and Visual Basic languages. These days, it's a toss-up.

If the person talks about writing web-apps, I'll tend to recommend Ruby and Rails as it has earlier ROI for a beginner, therefore a lot initially more satisfying.

This is somewhat tangential, but I'm pretty sure that Google re-writes the search code ever few years.

Yeah? Well, none of that search code is written in Python. It's C/C++.

See: http://stackoverflow.com/questions/754301/what-programming-l... http://stackoverflow.com/questions/923225/does-google-use-py...

I have been using Python for about year for Google App Engine projects. I have been using Ruby for about two years for various personal open-source projects. I like both languages, but I prefer Ruby over Python.

I hate Python's neglect (by Zed Shaw): http://www.zedshaw.com/blog/2009-05-29.html

Ruby seems to be so much more "symmetric", Python feels like a hack on top of dictionary to me.

What I will blame Python for is the lack of even the most basic time conversion features that even C has. If all they did was give me the exact same POSIX C API I’d be happy. Instead, I got some half-assed library and some half-assed rationale about why this is a better way to do it.

Ermm, datetime.strptime and datetime.strftime?

Any popularity in Python over Ruby stems largely from the fact that Python came first.

I've heard Python developer's working on a Ruby on Rails application that the problem with Ruby is that approximately equivalent to Python in terms of productivity. They wanted to use Python, but pragmatically you can't make the case to management to switch from one language to the other if the other language is more or less the same. But most of the time this effect works the other way around, where Python was established before Ruby.

I was doing Perl in 1999, and looked at switching to Ruby or Python. Python was still quite small back then, but you had web frameworks (Zope, Twisted), albeit the incarnations back then are clunky by today's standards, but Python was establishing itself as a clean, readable, dynamic language. Ruby on the other hand had no web frameworks, and almost no documentation in English - the only reason I was considering it was because I was working with a Japanese localization team and they thought Ruby was quite hot.

The debate over which dynamic or scripting language to use was always between Perl and Python back then. Perl was the incumbent and Python the challenger, Ruby rarely factored into the picture. It wasn't until Rails started to become useable and gain attention in 2004 and 2005 that Ruby interest started to really blossom. And so Python was well established for many uses: scientific computing, ad-hoc data processing, network programming. If you're a development manager of an application that you want to make scriptable, you would have made the decision to already go with Python, there just isn't any compelling reason to switch to Ruby beyond the sake of switching.

Another example is IronPython versus IronRuby: work started on IronPython in 2003, work started on IronRuby in 2007. IronPython is at version 2.0, while IronRuby is at version 0.5, and this is reflected in the polish of these language implementations. A .Net developer might decide that they prefer the idiosyncracies of Ruby over Python's idiosyncracies, but if they had to start a large project in today, they'd most likely choose IronPython since there is much less risk of the project bumping up against the rough edges of IronPython versus IronRuby.

Just my personal story, but perhaps extrapolating from it will help answer your question.

At my job I use Python because, well, at some point before I arrived one of the senior developers went on a jihad against Perl. :-)

I've read stuff about Ruby and while some things about the language intrigue me, it seems that any application you can build with Ruby can also be built with Python. If I'm going to learn another programming language in my Copious Free Time, I want to learn something really different from what I already know, not something that has pretty much the same features with different syntax and libraries. So Python wins by inertia.

Most of the discussion seems to ignore the "in this space" (scripting existing software packages) part of your question.

I submit that Python is more popular in this space because:

- many end users will be users of the package first, and programmers very much second. In this case a very gentle learning curve is more important than ultimate expressivity for hackers.

- In the same vein, it superficially looks more like BASIC than Ruby does

- The C API may be simpler to use than the Ruby interpreter, though never having used Ruby's C API that's speculation on my part. Never understimate implementor laziness as a technical driver.

I chose Ruby mainly because of all the syntactic tricks and weirdness but despite slowness.

You might choose Python for exactly the same reason; e.g., I wouldn't use Ruby on teams with >2 developers, especially in Google. Python is more straightforward but at a (small) price of freedom.

Example: you can rapidly prototype in Ruby using blocks and extend basic classes (even integer) using monkeypatching. I was fascinated by this, yet I wouldn't monkeypatch when working with other people so that advantage goes out of the window.

I think it's mostly about maturity, of the runtime, of the language, and of the community.

For example, Ruby has backward incompatibility issues in minor releases that would never be permitted in Python. They had to jump to Python 3 for even fairly small things that wouldn't be accepted in the 2.x line. Even subtle incompatibilities between Python versions are taken seriously, and there's a documented process for deprecation that involves multiple releases and means when a feature is deprecated it'll probably still be available for years. There's cruft in the language as a result, but for people using Python seriously this is more than worth it.

I think the Python-Dev community is also more mature. Changes get serious review. Though there's not a formal "core", strong objections from certain people are enough to bring a new feature back to zero and require a restart (not because those people have special weight, but because they are respected and everyone kind of understands there's a benefit to listening to crotchedy naysayers if they are smart crotchedy naysayers).

The community is large enough that there's a lot of domain knowledge. Python is better at getting a canonical and complete solution to a domain problem than Ruby. WSGI discussions for instance involved some people with a very intimate knowledge of HTTP. People work hard to get 95% solutions instead of 80% solutions. In part because Python has been around a long time, and there's already at least an 80% solution for whatever problem you are looking at, and if you are going to throw your hat in the ring you ought to be ready to try harder. I think the more aesthetic tendencies of the Ruby community work against it here, as people are more likely to rewrite for aesthetic rather than functional reasons. (OTOH, when Python settled early on some 80% solutions, it's caused a lot of difficulties because it's been hard to overcome inertia to introduce a better solution, while it's hard to get really good adoption of the 80% solution; pydoc would be an example.)

Then there's simple maturity. The VM is more stable; it may not be a great VM, but it is predictable. There's lots of tools for writing extensions. There's code for dealing with large data sets, for dealing with images, for accessing system libraries, etc. For any one problem Ruby might work fine, but for the problems you don't yet know you'll have to solve it's less likely you'll hit a blocker with Python.

Ian B., aren't you occasionally one of those crochety naysayers? :)

They're both equally Greenspuned to usefulness.

One major problem with Ruby has been that the performance as been much slower than Python. This is no longer true with Ruby 1.9. I happen to have done a benchmark using a recursive Fibonacci algorithm yesterday, results: http://pastie.org/528717 source: http://pastie.org/528720

I wouldn't say Ruby has lost just yet.

I don't think performance is holding ruby back I think that libraries especially mature and massive libraries, or lack thereof, is holding ruby back. Not to say people aren't working on it give ruby some time it will probably catch up especially with rails but just not right away.

Performance has always been a finger in Ruby's eye, but with 1.9 that doesn't seem the case.

Regarding libraries; you are right. Ruby has a lot of code out there, but much of it is in random repositories maintained by random people. Hopefully this changes.

Though it must be said, rubygems is miles ahead of anything available for python.

Can you explain more? Is there better native packaging (deb/rpm) etc support?

Rubygems is a separate system from deb/rpm, but works roughly the same way. Typically it doesn't do binary packaging the way they do it, though, and if native (non-ruby) code is required it is compiled during the install.

I'm not convinced that's true, as the depth and quality of rubygems are inferior to the depth and quality of eggs available in python. Find me e.g. a "gem install scipy" equivalent for Ruby.

However - "easy_uninstall scipy" REALLY needs to work!

My point precisely. I was referring to the package management system being better, not necessarily the packages available.

I believe the parent was referring to the rubygems system, not the quality of the gems themselves.

" think that libraries especially mature and massive libraries, or lack thereof, is holding ruby back."

JRuby FTW.

Yes, there are downsides to sitting on the JVM, but for anything other than one-off scripts, or where start-up speed is really important, JRuby gives the best of both worlds[0]: Ruby syntax with JVM libraries.

[0] Clearly if you do not care for Ruby syntax then this is not a win. I believe, though, that JRuby is more advanced and stable than Jython. But the Jython folks are quite capable for continuing to kick ass, so that will improve.

Just using Fibonacci for testing out VM performance is a bad idea. You need a broader viewpoint. That said, every language shootout is basically rubbish as there are so many variables who play into this.

http://shootout.alioth.debian.org/

When you say "win", are you meaning in the sense of "there can only be one"?

Why limit the discussion to Python and Ruby? Why not include PHP, say? Why have Python and Ruby "lost" to PHP? What about C++, Java and C#?

Heck, VB is still more "popular" than either: http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

I wanted to understand the factors that led to a particular outcome: Python becoming the de-facto winner for scripting applications.

I compared to Ruby, because that's the language I would choose for scripting, based on the ability to create nice internal DSLs.

Having used Python a while, unnecessarily marking out statements a second time for the computer using brackets is a waste of time, and ugly. I use older faster languages and put up with this, but don't see the point of doing so with Ruby.

Nearly all of the installers and packaging formats and management tools in Linux have Python APIs.

Edited as I wasn't clear the first time round: I love Python's wide variety string methods, and the emphasis people put on these rather than using RegExs all the time (sorry, I have more Perl and less of a Ruby background). Looking further it seems there's Ruby equivalents of most of my frequently used methods.

I love etrees in the standard library. People who use regexs for dealing with tree structured data are mental. Again, perhaps a Roby fan might enlighten me if there's a similar data structure in Ruby, I wouldn't be surprised.

"I love string methods. Not sure if Ruby also has them"

What do you mean? Of course Ruby has a String class and plenty of methods on it, but I'm not sure if that's what you're talking about.

Ruby comes with an XML library standard, sure, but it's pretty bad. In my experience most people use competing libraries, of which there are several high quality options. You can get a walkable tree from the core library but you'd be better off with one of the superior third-party libraries like hpricot or nokogiri.

(edited badly written original)

You're right, that was ambiguous, I've edited my post to clarify.

The behavior I'm referring to is loading XML into a tree shaped data structure, so you can reference particular branches when seeking or adding content, and not have to think about about tags (well, once you'veran it though BeautifulSoup or a similar cleaner).

That's OK, my reply was also pretty ambiguous :D

I am not really familiar enough with Python to say for sure but from what I know, XML libraries are probably superior on the Python side - in fact most "enterprise" interoperability libraries are probably better, or at least more mature. The situation on the Ruby side is improving rapidly, but given its history, yeah, many things like that are probably a little behind. Ask again in a couple of years!

The flipside of this, though, is that everything in Ruby is currently in a state of flux. The "winner" of the libraries is constantly changing and the rate of progress is actually quite staggering. There's excitement, momentum and willingness to embrace new ideas in the Ruby community that seems to exceed Python's.

So yeah. If you want stable, mature libraries that you can rely on for the next 5 years, Ruby is probably not the choice for you right now. If you want, however, to constantly live on "the edge" and see, say, 5 competing interfaces to the latest DB come out within days of its alpha release then Ruby's the go.

This is all fairly minor though - they're both great languages with great communities, I don't get all this "A vs. B" nonsense. There are certain libraries in Python that I wish were available in Ruby. There are certain libraries I like in Ruby that I know are not available in Python. My advice to a novice would be to choose the one whose syntax they prefer.

Python has similar issues tho - look at unit testing. The standard library has unittest, everyone prefers nose.

The "XML library" that comes with Ruby is REXML, which uses only regular expressions to 'parse' XML into the tree structure that it exposes via its API.

It is a stinking pile of shit.

Sure is! Actually, I can't even remember if it has the functionality nailer's talking about. As far as I know all rubyists permanently abandon REXML approximately 20 minutes into their first coding session involving anything to do with XML.

Gets to the point where other libraries are so common that they may as well be in core, though. I wonder if there's any rubygems installation anywhere that doesn't have hpricot.

"As far as I know all rubyists permanently abandon REXML approximately 20 minutes into their first coding session involving anything to do with XML."

No, not really.

Some do, I'm sure. I've had great success with it when I needed it.

Using edge cases in the syntax to construct an API with unusual calling conventions is not "writing a DSL." Unless you build a compiler/translator for it, it is not a "DSL," it is plain-old Ruby, happily accepted by any conforming Ruby implementation--nothing more.

After their pretentiousness, their arrogance, and their vociferous obnoxiousness, I find their misuse of this once-widely understood term to be their most annoying attribute. It seems like not a day goes by without some eager Ruby programmer hacking together yet another block-based API that kind of, sort of looks like Smalltalk if you squint enough, uploading it to GitHub or some similar site, and then slapping the "DSL" label on it, because Ruby, apparently, is just too cool and powerful a language to have mere "libraries" or "APIs."

What is this, bring out the Trolls day?

Ruby does in fact both have libraries and APIs (hyperbole aside). But none of what you've described is a reason why Python has become more prevalent than Ruby. This is just your personal bone to pick over nomenclature used by the Ruby community.

Rails is not the only piece of software in the Ruby community, and definitely not the most well designed (although it too is being improved significantly both in consistency and cleanliness in the push to 3.0).

Er, wrong.

Granted most things people call DSLs frankly are not, an internal DSL is a well known concept and repeatedly implemented in a lot of languages.

Both have their uses. I was a Perl hacker so Python was the obvious choice for me - but I would use Ruby for specific projects, for example if I desperately wanted a one-off app that primarily depended on a stable Ruby library where no Python one existed.

"I was a Perl hacker so Python was the obvious choice for me"

Interesting. I was a Perl hacker, and Ruby was the obvious choice for me.

Ruby feels like all the misery of Perl mashed into Smalltalk. Which is a shame, because I hear such good things about Smalltalk.

http://xkcd.com/353/ I need no other reason.

python is easy to learn like php and ruby have sometimes strange looking syntax like perl for newbies. A good programmer doesn't have this problem and will love the goodies and syntactic sugar from ruby.

php syntax is much more perl-y than ruby

NumPy.

Google SketchUp is scripted in Ruby

For embedding and scripting, I'd take python too. It'a s known value here, and I've heard ruby isn't so much.

When NOT talking about embedding or scripting, I'll probably take ruby.

1. Get latest OpenSolaris. 2. Install latest SunStudio 3. download latest source of Python (3.1) and Ruby (1.9.1). 4. Try to build them with CC=/opt/SUNWspro/bin/cc" CFLAGS="-m64" 5. See the results. Run make test for ruby.

So Ruby compiles cleaner on failed Unix OSs?

It's a bit harsh (albeit not completely off-base) to call solaris a failure but I do agree that c00p3r's argument is quite meaningless with regard to a ruby versus python comparison.

Both impls appear to work well enough on a wide range of platforms, the sun compiler is not exactly what makes or breaks it.

No. Its standard modules were coded more portable way.

btw, Solaris will stay on its niche like FreeBSD.

10 years ago Solaris' niche was being the standard OS at financial services companies. These days, that standard is Linux, generally Red Hat - nobody's buying SPARC anymore and Solaris on Intel runs very few apps. The largest hedge fund, the top tier investment banks, and the top retail banks have all abandoned Solaris. The only new purchases from Sun are support contracts on ancient kit that's still waiting to be replaced.

Our company provides and supports commercial builds of Python along with 40+ other packages (including scipy, numpy, PIL, wxPython, etc.) on Solaris. The Sun compiler is not great, but that has very little to do with Python.

The first (and only) thing you should do with with any proprietary UNIX's cc is to build gcc.

After that, your problem disappears.

Reply on news.ycombinator.com