I am pretty sure that's not what the author meant. Given the subject matter it's quite obvious that they meant: > In a closed world, these [two different ways,

I am pretty sure that's not what the author meant. Given the subject matter it's quite obvious that they meant: > In a closed world, these [two different ways, data vs. object, to represent two different instances of coordinates on which the same interface (in name and signature) is defined] are identical representations [of a data type bundled with a single method/function]. They are saying that the example in Java and the example in Haskell have the same expressive power. Both allow you to apply a distance function / method to a Coord type coord "thing", and depending on whether coord is a cartesian coordinate the cartesian coordinate based distance implementation is used and if it is a polar coordinate the polar coordinate implementation is used. Now, it would have been good for the author to acknowledge your point as well so as to avoid this misunderstanding. After all in the example, there is an underlying aspect / layer of things that can be substituted. I just don't think the author intended to talk at all about the actual (non) equivalence of polar vs. cartesian coordinate representations here. They'd probably say (and I'd agree) it doesn't matter at all for what is discussed. You could add a disclaimer saying "these coordinate types are both not actually equivalent" and it would not actually affect the validity of the points made. P.S. It's not even that the example is bad either. After all it's not uncommon in real codebases that two actual implementations of the same interface are producing subtly different results (e.g. calling into database engine A vs. B). Often these differences don't matter and the benefit of being able to exchange implementation / internal representation lies elsewhere (see DI).