Introduction

Ruby is the new boy in town. Until a couple of years ago, nobody really
spoke about Ruby. It was really popular in Japan, but outside it was just
one of the many ’scripting’ languages that the open source world has
developed over the years.

The big names were using Python or Perl. Well, most of them were using PHP,
but in fact this does not matter: while Perl, Python and Ruby are excellent
languages (even if it is almost impossible someone really likes both Perl
and Python, nonetheless Perl has its merits), PHP plainly sucks.
And then of course
there was that Java everybody was talking about and C# (but the open source
guys usually said positive things about it only if in the same sentence
the word ‘mono’ occurred).

In the last few years Rails changed things. Now a lot of people are talking
about Ruby and dynamic languages. A lot of Java developers discovered the
power of dynamic languages and dynamic typing, after years spent saying
that the only saviour was static typing. In fact it seems to me that there
is kind of a revolution in the IT world.

Python and Ruby and Lisp and …

Rails is a pretty good framework. The documentation is acceptable even for
those who grew up with Sun’s bloated documentation (I still prefer to read
the code if the language itself is readable enough).

Ruby is a really nice language. In fact you can see it as a (Perl–)++.
It kept almost all nice features from Perl, and dropped some of the worse.
Of course a Perl Monger would disagree, but I’m a pythonist after all.

One of the most interesting things, in my opinion, is that Ruby and Python
are quite similar (even if they start from different points of view). I feel
quite comfortable with both languages, and even their pragmatic is not
really different. Moreover differences tend to depend on different
syntax, rather than on different semantics.

For example in Ruby is quite frequent to ‘open’ classes and add methods.
This is something you can do in Python, even if there isn’t a special
syntax.

>> class A(object): pass
  >> a = A()
  >> a.foo()
  Traceback (most recent call last)
  ...
  <type 'exceptions.AttributeError'>: 'A' object has no attribute 'foo'
  >> def ext_foo(self): print 'foo'
  >> A.foo = ext_foo
  >> a.foo()
  foo

Of course this is far less elegant, and that’s way it’s something less
frequently done in Python.

Ruby has another ‘advantage’ over Python. It’s syntax is less rigid,
and in fact the most typical thing that is in Ruby pragmatic is to
write a DSL in the language itself and program in that DSL.

There are a lot of examples of this strategy in Rails itself. However, this
approach is not new at all. Lisp programmers have been using it since the
beginning, that is to say it’s almost forty years they code DLS in Lisp and
use them to write the application.

Duck typing vs. duck hyping.

Unfortunately I hear people saying quite often that ‘Ruby invented duck typing’. People that just
discovered Ruby, seem quite certain about it. Some of them even told me that
in Python you ‘were not really duck typing’ and that it was something
peculiar to Ruby. But let’s look at the definition (from Wikipedia):

Duck typing is a form of dynamic typing in which a variable’s value itself implicitly determines what the variable can do. This implies that an object is interchangeable with any other object that implements the same interface, regardless of whether the objects have a related inheritance hierarchy. Duck typing is a feature of programming languages such as Smalltalk, Python, Ruby, and ColdFusion.

Of course this is something that you can do in Python. And you can also do it in Objective C, by the way. And in Python it is something plainly obvious, too. Everybody does it, everybody likes it. But nobody thought about using a fancy name when describing the practice in books and blogs.

Amazingly, the term ‘duck typing’ (that some think it’s a Ruby peculiar feature) was probably used for the first time by Alex Martelli when speaking about Python typing system. It was Jul 26 2000, and the english language Ruby newsgroup had been active since the first days of may. There was a mailing list of course, but nonetheless Ruby was relatively unknown outside Japan.

In other words, don’t check whether it IS-a duck: check
whether it QUACKS-like-a duck, WALKS-like-a duck,
etc, etc, depending on exactly what subset of duck-like
behaviour you need to play your language-games with. If
the argument fails this specific-ducklyhood-subset-test, then
you can shrug, ask “why a duck?” (at least, you can if you’re
a Marx Brothers fan and have memorized “Cocoanuts”‘ script;
Monty Python one-true-wayists will have to find their own
simile here), and move on to the next set of tests (why-a-no-
chicken immediately comes to mind, but then one would have
to ask why it crosses the road, so I think we’d better snip it).

Alex’s original post

That is the reason why I say that Ruby supports ‘duck hyping’. Ruby is a very good language. I suppose that if I learnt Ruby before Python, I’d probably like Ruby more than Python (because the languages are quite equivalent, it’s my head that now works in a somewhat more pythonic way). However, there are a lot of people that are really *good* at selling Ruby. An excellent publisher based his early success on Ruby books, the creator of Rails has lots of marketing skills, and so on.

However, I was wondering: why Ruby and not Python? I don’t believe in fortune. To discover the answer (that in this particular case I guarantee it’ s not 42) we must analyze in which ways syntactical features of Ruby (since semantically they are quite interchangeable) influence the language pragmatic, and in which ways the pragmatic contributed to build Ruby success.

And when we are into pragmatic, we are not in the world of the compiler: we are in the world of the programmers. That is to say: we must understand why Ruby has appeal even where Python has not. We must understand in which way the language influenced the way of thinking of so many people, and why Python did not.