The case against duck typing 2009/09/12
It’s a common enough argument to bear documenting once and for all. Rubytards and cheese shoppers (that is, Python programmers) always gang up on me because they love ducks. I’d rather the ducks stay out of my type checking, that’s all.
Take this (contrived, as Mike Malone loves to point out) example of
what can go wrong with duck typing. Your revenue-generating web
app deals in kittens and dollars so you have classes called
CreditCard, both of which have
a method used to stringify them:
class Kitten(object): # ... def __unicode__(self): return """<img src="%s" />""" % self.src
class CreditCard(object): # ... def __unicode__(self): return "XXXX-XXXX-XXXX-%s" % self.cc[-4:]
If some HTML template requires merely something stringifiable, a
CreditCard will do just as well as a
To prevent mishaps, the caller must first check the type of the potential
kitten or the
CreditCard classes must
be made different species of duck. While the latter is certainly
cleaner from the caller’s perspective, it (pathologically) results
in every method of the
Kitten class being prefixed
kitten_" to avoid calling a goose a duck.
Of course, this example was invented for the express purpose of making duck typing look awkward and dangerous. Long before it gets to that point, I think it crosses into confusion. Looking at a method signature written in any popular dynamic language gives the caller no instruction beyond (maybe) the number of parameters expected. If you’re lucky, the names of the parameters shed some light. Perhaps someone’s gone all Javadoc and written out comments that explain what the hell’s going on.
I am not an advocate of regressing back to statically typed languages for all programming (though it’s well-known I’m a big C++ fan). I want declared typing. Methods should state what they accept in such a way that the compiler can enforce this on our behalf. PHP 5 introduced type hinting  as a half-assed way to accomplish this. For objects and arrays (but not integers, floats and strings), PHP can automatically raise “catchable”  fatal errors when types don't match up as you intended.
While PHP’s solution is half useless for not working on
primitives and half again because you can’t deal with the error
and move on, the heart is in the right place. Declared typing is
for the programmer using the API your code creates. A compiler
saying unambiguously that you passed a
Sailboat when you
should have passed a
Bulldozer is delightfully useful when
compared to curious “method not found” errors. Worse
still is the subtly incorrect behavior introduced when somebody
In a nutshell, I wish for the clarity I get from reading statically typed code with the power of dynamically typed languages.