I think you are talking about a different domain than the author. The author is talking about writing plumbing code - the parts where everything is reusable and

I think you are talking about a different domain than the author. The author is talking about writing plumbing code - the parts where everything is reusable and multipurpose. In contrast, you seem to be focusing on the business logic portion of the domain where all complexity is necessary. In the reusable abstraction space, what you're talking about just doesn't happen. There aren't bugs that need to be hunted down by careful inspection in these things because the methods described in the article are sufficient to catch them. They'll fail to type check or have obvious flaws of the sort -Wall catches. In the business logic domain, there is a lot more room for errors that can't be caught by those approaches. But code in that domain also can't be written like this in the first place, so it's kind of a strange criticism to say "the code I can't write like this contains bugs that are hard to track down when I try to write it like this." I can sense one additional objection coming: "If this isn't for business logic, what value is it? I write business programs." To that, I would answer that most programs are stuffed full of redundant non-business logic, and you don't even realize how bad it is. It took roughly 30 years of c-like languages for people to be fully on-board with the idea that 3-clause for loops are error-prone boilerplate separate from the business logic and worth abstracting out. If you use Haskell enough you'll realize a lot of your code in most languages is there to fiddle with implementation details instead of working over the actual problem space. A lot of Haskell code takes the form of super-generic abstraction plumbing bits that serve to isolate a common pattern and make sure the edge cases are covered. Those bits of code are the ones usually called "impossible to understand", which are fully described by their types, and which can be implemented with this approach.