My avoidance of OOP predates my use of FP like most people I know.. As imperative C programmers of old, we often had to deal with people trying to add C++ on to

My avoidance of OOP predates my use of FP like most people I know.. As imperative C programmers of old, we often had to deal with people trying to add C++ on top and then needing help.. Their projects were often months of work and a total failure because they had fractally encoded their model into how their code, data and model operate. Inevitably a few of their ideas of that model were wrong or needed to change for unexpected reasons and are encoded across all sorts of things via inheritance and method parameters. Essentially they have invested in huge blocks of take it or leave it nonsense similar to the banana quote in the article. I get the same general feeling from FP OO as normal classical OO. There seems to be a need for a hierarchy in parts of base type systems and other standard library pieces, but once some framework layer declares a class to be extended you just have bug after bug that all relate to an imaginary hierarchies invented because everyone needed to provide a nail for the OO hammer. Personally, I'm much happier with interfaces that rely on a duck style to implicitly define types with implementors. I find it sad that some older languages are reimplementing classes when it seems like newer ones have correctly moved on to no unique relationship hierarchies in general code.