Introduction
Ruby is the new boy in town. Until a couple of years ago, nobody reallyspoke about Ruby. It was really popular in Japan, but outside it was justone 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 coursethere was that Java everybody was talking about and C# (but the open sourceguys 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 talkingabout Ruby and dynamic languages. A lot of Java developers discovered thepower of dynamic languages and dynamic typing, after years spent sayingthat the only saviour was static typing. In fact it seems to me that thereis 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 forthose who grew up with Sun's bloated documentation (I still prefer to readthe 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 Pythonare quite similar (even if they start from different points of view). I feelquite comfortable with both languages, and even their pragmatic is
notreally 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 specialsyntax.
>> 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, thisapproach is not new at all. Lisp programmers have been using it since thebeginning, that is to say it's almost forty years they code DLS in Lisp anduse 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 thatin 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.
