4 ms·

> Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. This was just an ex

> Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. This was just an example of a behaviour that, if taken too far, could eventually lead to those 'hundreds of lines of abstract code'. Of course a single fold in itself is nothing to be concerned about. But an API that accepts a type 'm a' instead of '[Order]' has lost some of its connection with the business domain already. Again, this might not be bad, it can even be good, but the problem is that many FP enthusiasts overdo it. > In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with. Yes, this is the same problem which pops up in the OOP world as well. I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it.

cannabis_sam 6y ago
> '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)

cannabis_sam 6y ago

> '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)