The author uses the term ad-hoc polymorphism in a completely wrong way. I will ignore this.
The problem the author tries to explain has nothing to do with polymorphism at all. It has to do with interfaces, and it exists even in languages that don’t have generics at all. If you rely on the behavior of an interface more than an interface declares as its type, then of course changing the implementation of the interface can break your code.
Hardly a revelation.
Interfaces of any kind, be it APIs, C function pointers, Go interfaces, OOP abstract classes, Haskell typeclasses, Rust traits create a programmer-defined arbitrary ordering between types. If this ordering doesn’t match the behavioral ordering expected by the programmer, then of course something is amiss.
If you don’t use interfaces, then of course you cannot misuse interfaces.
I read this from TWiR. To my limited knowledge of Haskell, the “bad” Haskell code looked like code that one reasonably might write, but the “bad” Rust code — getting the number of items in a container by iterating over the container rather than simply reading the container’s length field — looks unidiomatic to me and not like code that one would be likely to write in practice in Rust, unless it seem much the least bad option in one’s specific situation.
As the whole argument seems to be based on extrapolating from this single example of something one might write in four ways ({Haskell, Rust} × {monomorphic, polymorphic}), that this example is unconvincing makes the whole argument unconvincing to me.
The author uses the term ad-hoc polymorphism in a completely wrong way. I will ignore this.
The problem the author tries to explain has nothing to do with polymorphism at all. It has to do with interfaces, and it exists even in languages that don’t have generics at all. If you rely on the behavior of an interface more than an interface declares as its type, then of course changing the implementation of the interface can break your code.
Hardly a revelation.
Interfaces of any kind, be it APIs, C function pointers, Go interfaces, OOP abstract classes, Haskell typeclasses, Rust traits create a programmer-defined arbitrary ordering between types. If this ordering doesn’t match the behavioral ordering expected by the programmer, then of course something is amiss.
If you don’t use interfaces, then of course you cannot misuse interfaces.
I read this from TWiR. To my limited knowledge of Haskell, the “bad” Haskell code looked like code that one reasonably might write, but the “bad” Rust code — getting the number of items in a container by iterating over the container rather than simply reading the container’s length field — looks unidiomatic to me and not like code that one would be likely to write in practice in Rust, unless it seem much the least bad option in one’s specific situation.
As the whole argument seems to be based on extrapolating from this single example of something one might write in four ways ({Haskell, Rust} × {monomorphic, polymorphic}), that this example is unconvincing makes the whole argument unconvincing to me.