Duck typing is central to the Smalltalk "vision thing". That and the idea that a message is a symbolic representation of a method, which an object may or may not support. It is not, in fact, the method, nor does it stand for a direct call to the method. In C++ and Java, for a call to a.foo(12) the compiler can look up the class of a, determine whether it has a foo implementation, and if so compile a call directly with the number 12. In Smalltalk, a foo: 12 has no such implications. Rather the runtime will look up whether a's class has a foo: method at call time and if so, invoke that method; otherwise invoke the object's doesNotUnderstand: method with the message and arguments as parameters. There's an added layer of indirection there. It's rather like a single-threaded Actor model. Kay was trying to get people to think in terms of encapsulated objects that communicate in (often ad hoc!) ways, not in terms of inheritance trees or type hierarchies.
Is it better? Is it worse? I don't know. We know Smalltalk is slower, but it (along with Objective-C) admits designs unfathomable in C++. For example, all objects that understand a given protocol (set of methods) and implement it in a sensible way are substitutable with each other (with respect to the protocol) irrespective of their place on the inheritance hierarchy (or even whether such protocol was formally defined). This is NOT true with C++, absent template metaprogramming, and it's not true with Java unless you define an interface and assert that all classes which understand those methods implement that interface.
Furthermore, by overriding doesNotUnderstand:, you can specify a behavior for classes when sent a message they don't have a method for, besides raising an error. Maybe you want them to forward the method to one or more delegate objects, or log the invocation.
It's super-flexible, powerful, and neat in a similar dynamic-language way to how Lisp is neat. That's why Smalltalk attracts so many fervent converts. As I said, it can be better or worse depending on your perspective. Some people like working with type hierarchies; Haskell, Rust, and even C++ attract fervent converts too!
> ... all objects that understand a given protocol (set of methods) and implement it in a sensible way are substitutable with each other (with respect to the protocol) irrespective of their place on the inheritance hierarchy (or even whether such protocol was formally defined)....
This is a very interesting property, and you'll also see it in statically-typed languages which support row polymorphism, like OCaml. OCaml directly supports OOP and subclassing, but it also supports structural typing, which means that objects are type-compatible if they support the same methods.
Unlike Smalltalk, this is all resolved at compile time, so it's quite efficient.
Introducing template metaprogramming comes with its own passel of problems: compile times (and code size) can explode, and then there are the difficult-to-debug error messages if you screw up. Because Smalltalk uses latent types, these decisions are deferred till run time, which is a loss for static analysis, but doesn't require a separate generated bit of code for every combination of arbitrary types used in the program, and it can be debugged on the spot without recompiling much more than a single method.
> Introducing template metaprogramming comes with its own passel of problems: compile times (and code size) can explode, and then there are the difficult-to-debug error messages if you screw up
I don't know any even remotely large recent C++ project that does not use templates at some point. Templates are central to C++ since Alexandrescu's book and the main point around which the current language revolves.
Template meta-programming is a different usage from template generics. It has a higher compile time cost because it performs computations as a side-effect of compilation.
Which is what the commenter above was trying to say, templates are completely normal, vanilla C++. Also, I cannot think of any codebase that is actively under development and doesn't use some template magic, like at least tuples or variadic perfect forwarding etc... If you look at old codebases you can find them, but template metaprogramming is still very common, mainstream C++.
Is it better? Is it worse? I don't know. We know Smalltalk is slower, but it (along with Objective-C) admits designs unfathomable in C++. For example, all objects that understand a given protocol (set of methods) and implement it in a sensible way are substitutable with each other (with respect to the protocol) irrespective of their place on the inheritance hierarchy (or even whether such protocol was formally defined). This is NOT true with C++, absent template metaprogramming, and it's not true with Java unless you define an interface and assert that all classes which understand those methods implement that interface.
Furthermore, by overriding doesNotUnderstand:, you can specify a behavior for classes when sent a message they don't have a method for, besides raising an error. Maybe you want them to forward the method to one or more delegate objects, or log the invocation.
It's super-flexible, powerful, and neat in a similar dynamic-language way to how Lisp is neat. That's why Smalltalk attracts so many fervent converts. As I said, it can be better or worse depending on your perspective. Some people like working with type hierarchies; Haskell, Rust, and even C++ attract fervent converts too!