The conclusion indicates where you stopped thinking

In a technical article, the conclusion usually indicates where you became tired of thinking, and want to leave the rest to the reader.

When doing analysis, I need to recognize behaviour in objects. In design, the type I give to my objects is the conclusion I reach. Programmers tend to favor duck typing because it allows them to skip the part where they have to build and recognize abstractions, and they can simply implement all needed objects without actually giving them a type.

When using duck typing, if an object implements walk() and quack() they can treat it like a duck, but they do not have to define exactly what a duck is, nor do they have to explicitly recognize duck behaviour in their objects. More precisely, they longer need to reflect the is-a hierarchy using types, but simply a behaves-mostly-like hierarchy using classes. This is of course much simpler to design, as they may throw theoretical issues (like the Liskov Substituion Principle) out of the equation.

When using static typing, I have to recognize up front that my function requires duck-like behaviour, I have to precisely define what duck-like behaviour means (that is define a type, not a class, in the form of a DuckInterface) and identify precisely which classes in my hierarchy exhibit duck-likle behaviour (and make them implement the DuckInterface.)

Static typing does not limit my expressiveness. It merely forces me to think about what I'm saying before I actually say it. It means that I have to carefully identify the abstractions and design the corresponding interfaces. It means that I have to recognize the difference between subtyping and subclassing.

I am reasonably good at building and recognizing abstractions, and that is why I don't usually need duck typing. If you are not good at handling abstractions, then you will find that duck typing greatly simplifies your work. Consider it the "lite" version of object oriented analysis and design. You do not define types, you just let the reader discover them.


However, the lack of clearly defined types has its price: interfaces are the building blocks of loose coupling, so you need to design them anyway. In duck typing, interfaces will tend to emerge from the code instead of the analysis; this might not be the best way, as you usually end up with ad-hoc types instead of carefully thought ones.