One of my readers sent me a link to this artcle on "duck typing" (i.e., what Smalltalkers have called dynamic typing for eons now). Here's the part I found incoherent:

First of all, let's get a frequently asked question out of the way: if two interfaces have the same methods, are they semantically equivalent? Isn't there a risk to pass an object that is totally wrong for this method, yet will work because it responds to the right methods?

I don't have a clear answer to that, but my experience is that such a thing is very unlikely. This kind of argument is a bit similar to the fear we all felt in the beginning of Java when we realized that containers are not typed: ClassCastExceptions end up being much more rare than we all thought.

Duck Typing is a big time saver when you write code, but is it worth it? Don't you pay this ease of development much later in the development cycle? Isn't there a risk that you might be shipping code that is broken?

The answer is obviously yes.

So the sorts of errors the author fears are virtually non-existant, but they introduce a huge risk of shipping broken code. Excuse me? Is it just me, or is the author arguing with himself here?

One of the things I really like about this mode of argument is that testing isn't sufficient - we need something stronger (enter declarative typing). If that's the case, why do people writing in C++, Java, or C# even need to test? Doesn't the typing obviate the need for it? The point is, you need to test anyway. If a given paradigm - dynamic typing in this case - increases productivity - and if declarative typing doesn't obviate the need for testing (it doesn't) - then what does the typing buy you? Better arithmetic performance, mostly. That's useful for a small range of applications (and, for most of those, we can use a high level language like Smalltalk and mixin lower level languages for the performance critical sections. Plenty of our customers do just that.

The author comes up with a contrived example to show that declarative typing will save you from a potential runtime nightmare. I say contrived because I've written code using the kind of API he talks about many, many times. Want to know how many times I've walked into the minefield he fears? It's a small number, except for the larger values of zero.

The best part of the whole thing is the comments, where some of the responders claim that refactoring tools are "impossible" in languages like Smalltalk. Times like this I wonder how many people realize that all the cool stuff that people think came from Java - like refactoring support and unit testing - were invented in Smalltalk more than a decade ago.

I swear, this entire industry actively engages in amnesia...