> 'hundreds of lines of abstract code'. Yeah, I’ve spent way to much time digging into “hundreds of thousands” of lines of abstract OOP code. And it’s sadly,

> 'hundreds of lines of abstract code'. Yeah, I’ve spent way to much time digging into “hundreds of thousands” of lines of abstract OOP code. And it’s sadly, largely ceremonial, mostly due to limitations in the language. The less fanatic about OOP the language is, the more useful it is, is a good rule. But it’s absolutely not exclusive to either paradigm. > But an API that accepts a type 'm a' instead of '[Order]' has lost some of its connection with the business domain already. I completely agree, but I’m also curious how any API interface like that would pass code review. Since it’s so obviously too general. But I guess the perceived upside is that the equivalent oop-construction would not get caught in code review. > Yes, this is the same problem which pops up in the OOP world as well. I know. I’ve spent more time working within oop than without. The type based FP-world just have orders of magnitude better tools. > I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it. This is kind of a sad way to dismiss people, as if they’re some kind of ephemeral fireflies... The reality is that trying to force reality into in an inheritance-based, tree-structured taxonomy, is not only stupid, it also creates endless maintenance headaches. Some problems fit that model better sure, but most things fit a much simpler ADT-based model since it’s much closer to how we think logically. (In terms of logical primitives and implicit recursion)