>The people who did this will mess up FP or any other paradigm too. The people who did this will not mess up FP or any other paradigm. I have an example of th

>The people who did this will mess up FP or any other paradigm too. The people who did this will not mess up FP or any other paradigm. I have an example of that somewhere in my career, with Haskell. But it is "he said she said" here and it is not me who started that. >you have to have good taste and recognize when something you do is going off the rails The Liskov substitution principle is not precisely defined, see the "shapes" problem (class Rectangle : Square or vice versa?). Thus, you have to have "a good taste," or, to be more reality grounded, you have to weigh your design choices against current use cases and possible future changes. When you deal with constraints on a type, you don't need hierarchy at all. If you add two values of some variable type in a function, assure function's type to have Num constraints for the type of these two values. Then pass there anything that has Num implemented and be fine. The inheritance in typical OOP program fixes solutions of historical use cases in place and prevents finding more general solutions when new use cases arise. The solutions for new uses cases most often get bolted on instead of being organically implanted. Basically, it is OOP that provokes such concatenative names. When you step outside, you find yourself in no need of these.