Why Dynamic is better

It walked like a duck, and quacked like a duck ... but when we tried to make it into duck sandwiches we figured out it was a childs toy. If only the the object had been labelled 'duck toy' we might have figured out there was something wrong before we paid for it in the store.

The sorts of edge cases and issues being debated simply don't come up for Smalltalkers.
Just as issues of air bag design don't come up for cars without air bags - obviously cars without air bags must be better! Or are we forgetting something?

Generic programming via duck typing is all fine and dandy, but sometimes it's nice when you can tell the compiler what you expect as an argument, such as in Dylan:

define method foo (bar :: <number>)
    // bar must be a number
end

I like catching errors where they start, not a few calls up the call stack with a confusing error message.

Comment by Alan Knight

The air bag analogy seems rather ill-chosen. Having air bags is much more like the Smalltalk mechanisms - it protects you if you run into <grin> something you didn't expect, at the exact moment you run into it. A static mechanism would be more like an automatic guidance system that can guarantee you'll never run into anything. Or better, one that could prove mathematically in advance that you'll never run into anything. And once we have those that work nicely without restricting where you can drive, I'm sure they'll be very useful, and we can optimize by removing the air bags.

As far as the Dylan example, I always thought that the place the problem occurred was where you tried to use an object in a way that it didn't support. And one advantage is that if that doesn't happen, you may discover that the conditions weren't as restrictive as the designer imagined, and that your code can, for example, actually work when passed complex numbers, or vectors, or other interesting objects. Also, if you only tell the compiler that in a few places, it's equivalent to putting in an assertion, and doesn't help the compiler in its attempt to prove those errors can't occur, as it tries to make sure the program is right before we're allowed to know if it works.

"sometimes it's nice when you can tell the compiler what you expect as an argument"

I am sure you can get over this inclination with a little practice.

Alan Knight wrote The air bag analogy seems rather ill-chosen.
The analogy I made was fine - Smalltalk doesn't have issues with generic types because Smalltalk doesn't have generic types, and doesn't gain any of the benefits that may follow from having generic types.
You chose to make up something different.

The vacuous quacking about ducks always conveniently neglects to mention that it's the unfortunate user who finds out it doesn't walk and won't quack, when they are trying to get some work done.

I take more seriously the people who promote novel ways to beat out defects from the code, like static bytecode analysis for dynamically typed Erlang, like type inference for Smalltalk.

The more ways to beat out defect from the code, the better.

Comment by James Robertson

Less is better. To draw another partially flawed analogy, your theory about more being better is like theorizing that adding more laws - in order to more tightly proscribe what can and cannot be done - is better.

Life isn't statically typed. Languages shouldn't be, either