> Most people (me included) will instinctively reach for the class structure where Natural is the base class, and Integer extends that base. Huh? Why? That's m

> Most people (me included) will instinctively reach for the class structure where Natural is the base class, and Integer extends that base. Huh? Why? That's mathematically nonsense, so why would you encode it in your type system? Naturals are a strict subset of Integers. The Liskov substitution principle applies perfectly well when you set this up the right way. And guess what: actual "numerical tower" implementations (yes, even in languages with object systems like Common Lisp and Python) don't work this way either. For example, in Python, the numerical tower is literally the opposite of what is proposed here. The base class is Number. Then Complex inherits from Number. And so on down to Integral, which is the most derived number type, not the most basic. The numerical towers in Common Lisp and Scheme behave similarly. They all differ in structure details, but they all work the same way: the largest collections are the most basic types, the smallest collections are the most derived types. This whole article is complaining about OOP being bad, when in reality OOP is helping to reveal a fundamentally bad design, which would be wrong in any programming paradigm. There's nothing wrong with Peano numbers of course, but to introduce them in order to avoid fixing your unsound conceptual model, and to claim that it's an improvement over the OO-with-inheritance approach, is just silly. It's certainly interesting that OO inheritance only supports "subset" relationships and not "superset" relationships, which I think is maybe what the author was originally trying to illustrate. It's something we do in math all the time. But that's not where the article goes and that's not what it presents as its own conclusion. --- Edit / addendum: You can build up a class hierarchy "additively" (adding structure/operations in more-derived types) rather than "subtractively" (removing structure/operations in more-derived types) using mixins in OO or type classes in FP. The author mentioned Haskell and went so far as to define a custom ADT for integers but didn't notice that Haskell itself has its own kind of numerical tower in its type classes Num, Integral, etc. which works in exactly the additive style that they realized was incompatible with traditional OO inheritance.