I'm not sure I'd agree with initial statement (and by this I literally mean - "I am not sure", its not a figure of speech). I agree with everything else you sa

I'm not sure I'd agree with initial statement (and by this I literally mean - "I am not sure", its not a figure of speech). I agree with everything else you said, but the way I see it - when a paradigm cornerstone itself starts getting in the way of code organization, then that's a clear sign that paradigm itself is 'wrong', or more precisely, wrong when applied to this set of problems. Oooooooh, look at that, I understand now what you meant :-D Regarding your second paragraph - this is, looking from efficiency standpoint, the best approach. Additional gain is in access control: it becomes flat (ie. module-controlled), rather than having a class hierarchy in between, and then using messy constructs such as interfaces/mixins to achieve both code and type inheritance. Raise hands if you ever ended up in situation where you have to convert from one type to another, while the actual data they carry are precisely the same. Raise hands if you ever had to pollute an interface or a parent class with extra data, because a subclass somewhere contains exact data needed at the other part of the chain. This is friction - and it works against the developer/team. The larger the software, the worse it gets; it doesn't have to be that way. Anyways, regarding last two points - yes, I'm very familiar with parametric polymorphism (it is a sole reason I use C++ for work, over C), and I have than half a decade of Haskell experience behind me. Trying to shift into Rust lately - its easier to find jobs.