The best kittens, technology, and video games blog in the world.

Thursday, September 21, 2006

Fight to the death between Ruby and Python

Peeking Lunu by special combo from flickr (CC-NC-ND)Recently there has been a big surge in popularity of both Ruby and Python. And with it came countless discussions on which one is better than the other. Volume of such discussions baffles many people, who think that the whole thing is pointless because the differences are very tiny, and both languages are converging anyway into some sort of Rython or Puby.

However this is completely backwards - the fight is so fierce because Ruby and Python are pretty much identical, not in spite of it.

There is a well-established principle in ecology called "competitive exclusion principle" which says that no two species can occupy the same ecological niche for a long time. They either get specialized, or one of them becomes extinct. A similar mechanism exists in many other fields - including programming languages. If you have two languages - like Ruby and Python, competing for exactly the same ecological niche, and one of them marginally better than the other, what is the purpose of the other language's existance ? Even if the difference is really tiny, who would want to use a less powerful language ?

If the difference in power is really tiny, like in case of Ruby versus Python, it would be reasonable to guess that it will take a very long time before one kills the other. However, "evolutionary fitness" of a programming language has two components:

  • Power (expressiveness, performance etc.)
  • Popularity (which results in more libraries, better tools, fewer bugs etc.)
This greatly amplifies effects of competitive exclusion - if one language is gaining popularity because of somewhat better fitness, it gets more libraries etc., what increases difference in fitness even more, and in no time we have a clear winner.

Now Ruby and Python are almost identical. If you asked a Ruby programmer to take any language other than Ruby, Python would be the most popular choice. Likewise, if a Python programmer had to take a different language, they would most likely take Ruby. And in a few years one of them will survive and the other will either die or will get relegated to a small niche, and which of them survives depends mostly on which of them gets marginally better fitness right now - Ruby is a bit more powerful, Python is a bit more popular, and the situation is very unstable. The small difference today will get amplified.

So if you want Python to win:
  • Reduce the gap in power - make Python support blocks, get rid of explicit self and get better support for metaprogramming. If Python did it a few years ago, nobody would have heard of Ruby. If you don't like blocks, metaprogramming and implicit self, you don't have to use them - simply consider them a price to pay for making Python the next big thing. If it gets them today, it is still very likely to win.
  • Reverse gap in power - can Python express certain things a lot better than Ruby ? Write useful programs and libraries that would be much more difficult without this power and popularize them. Attack the enemy where it is strongest.
  • Make the most of greater popularity - work on useful things that are very useful but hard to reproduce with smaller user base - like Psyco and stable ports to JVM and .NET.
And if you want Ruby to win:
  • Increase power advantage - take powerful features from Lisps, Smalltalk, Erlang, Haskell or whatever, and integrate them with Ruby - making different paradigms work together is one of the greatest strengths of Ruby, so make use of it. Make metaprogramming and DSLs easier by writing metalibraries and tutorials.
  • Make the most of greater power - Ruby was able to get the momentum with Ruby on Rails, which would be very difficult to replicate in other languages. Ruby makes writing powerful embedded DSLs very easy, and powerful embedded DSLs are a potentially huge and pretty much unfilled niche. Take it and use it as a leverage to get more popularity.
  • Minimize effects of lesser popularity - if Python has a good library for something, simply recode it to Ruby and call it version 1.0. The languages are so similar that you should be able to do it in no time. You can get it more Ruby-like (with blocks etc.) later.
  • There are some things in which current implementation of Python is simply better - Ruby 2 is trying to fix many of those (you cannot have Ruby Psyco without YARV). If you can - help with Ruby 2.
And in either case:
  • Steal every single cool feature from the other language, indiscriminately. You can deprecate the ones that didn't work later.
And in the end, whether Rython or Puby wins, you will feel at home having a great language.

14 comments:

Anonymous said...

I used to agree with your thesis that one or the other language will 'win' leading to the death of the other. Now I don't really think so. While the niche is similar, each language seems to appeal to a different mindset and you see that exemplified in the types of communities which have grown up around the languages. Ruby's ease of metaprogramming leads to it being used by those who are really into metaprogramming, for example. Python's 'there's only one way to do it' philosophy appeals to a very different set of folks than Ruby's (and Perl's) 'there are many ways to do it and we're not going to dictate which one you must use' philosophy.

At this point I think both languages will co-exist for quite some time into the future (several years at least).

In reply to Fuzzyman:

Ruby 'on it's own' is used a lot more than you would suspect outside of the realm of web programming. I've used it as a key part a code generation framework at a Very Big Company(TM). I've also used it as a cross-platform installation tool for a CD also released by the same Very Big Company(TM) - Ruby's there on the CD, though it's cleverly hidden and thousands of said CDs are sent out every year.

Anonymous said...

One thing Ruby should work on is performance issues, it's been getting a lot of slack for being too slow... See the language shootout comparison for example, Ruby is consistently slower.

And that's using Python 2.4.3, so it doesn't include all of the Python 2.5 "NeedForSpeed" performance improvements.

taw said...

anonymous: Ruby and Python have completely different philosophies, but it somehow leads to a very little practical difference. I'd say "language philosophies" are more about marketing than about technology, as in every language (including Python) there are multiple ways of doing most things, and only one or two of the ways are actually used in real code (even in Perl).

Ruby performance issue is mostly about popularity. There is nothing about Ruby that makes it particularly slow - it just needs a lot of work and it can most likely get as fast as Java. People are working on it right now, so it is likely this problem will disapear soon enough.

Josh said...

I tend to think that if Ruby get YARV working, it is going to win. The only real knock against Ruby is that it is slow. Once it is no longer slow (even if it just matches Python's current speed) people are going to give it a try. It can be used for a lot of different tasks and is an excellent glue language.

Another possibility is that the language that wins is the first langauge to be compatable to the other. For example, if Ruby gets YARV, and the Python people find a way to compile Python to be YARV compliant, then Python will win because Python can use Ruby stuff, but Ruby can't use Python stuff (in this example). It could easily happen the other way around. The language that gives people freedom to use all their existing code (no matter the language) is likely to dominate. It eliminates the biggest cost to changing languages, which is that you can't use your old code.

taw said...

Josh: I wonder, people often make an argument that Ruby is slower than Python, but how big is the difference ?

Are there any real world cases or realistic benchmarks that can estimate it ? I was only able to find "microbenchmarks" that try to find out which language is better at computing Fibonacci function etc., but this is just too unrealistic.

Anonymous said...

some of us are totally sick of Perl, and can see the obvious Perl-isms throughout Ruby, but not Python. If Ruby wasnt so perl-oriented i would have used it.

Anonymous said...

When Ruby gets some actual documentation for it's stdlib, I might have another look - an automatically generated API listing is not documentation.

Anonymous said...

How is that language shootout unrealistic? Granted you may not be trying to create fractals yourself, but you can't just dismiss how poorly Ruby performs right now for anything CPU intensive (ie: not web apps where most of your time is spent in the database).

taw said...

Anonymous: Ruby has a few Perlisms and Smalltalkisms to make Perl and Smalltalk programmers feel at home, but Perl's mistakes (like moving type information from objects to operators - "==" vs "eq" etc.) were not copied. Making people feel at home really helps adoption. I have no idea which features of Perl annoy you so much.

Another Anonymous: I consider Ruby documentation and RDoc one of Ruby's greatest strengths, not weeknesses. Well, except that default output format of RDoc sucks.

The great thing is that it works online. You write help('whatever') in Ruby and you get good documentation for each method. Or you can simply ask objects, with foo.methods, Bar.ancestors, buzz.class etc. In Python you only get method listings with one-line summaries. It's still useful, but I miss Ruby's functionality when I'm coding Python.

taw said...

One more anonymous (it would be easier if people signed, especially as Blogger has no threads): Operations in high-level languages tend to be slower, but as you need fewer of them, performance isn't that bad. Most microbenchmarks make a lot of simple operations - like adding numbers in a loop, and are typically specified in a way that doesn't make it possible to use high-level features ("same way" instead of "same thing").

Real applications tend to use fewer but more complex operations, so high level languages aren't anywhere as bad as microbenchmarks would suggest.

This probably does not affect Ruby vs Python much, but it would have great effect on comparisons like Ruby vs C++.

Anonymous said...

It bugs me that people keep saying Ruby is only for Rails. Ruby was around for quite a while before Rails came along, has carved its place in many a niche, and IMHO is a much nicer project than Rails anyway.

It also bugs me that people keep complaining about Ruby slowness, a minor issue for this kind of language, instead of addressing its two major flaws: lack of Unicode awareness and lack of good standard documentation. Python wins hands down on both counts.

Anonymous said...

Taw: "It's still useful, but I miss Ruby's functionality when I'm coding Python." (talking about the 'help' function)

Python most definitely has a 'help' function that you can call on any object and get it's documentation + available methods (and their documentation) + members.

Also, documentation is much more than just "one-line summaries"; docstrings often start off with a one-line summary, but also include usage examples, explanation of arguments and return values, etc. Many folks have already argued that the documentation for the standard lib in Python is better than Ruby.

Anonymous said...

Ya, I agree document on stdlib is a big short of ruby. Unicode is another headache, yet I'm happy to see rails multibyte plugin has done some nice works. Hope it will be merged into ruby core soon.

Isaac Gouy said...

TAW wrote Are there any real world cases or realistic benchmarks that can estimate it ? I was only able to find "microbenchmarks" that try to find out which language is better at computing Fibonacci function etc., but this is just too unrealistic.

and TAW wrote Most microbenchmarks make a lot of simple operations - like adding numbers in a loop, and are typically specified in a way that doesn't make it possible to use high-level features ("same way" instead of "same thing").

anonymous 9:50 PM referred specifically to the computer language shootout, and you seem to have responded with generalizations - did you even look at the programs shown on that website?