Note that Haskell makes very few assumptions about the users; the quality and complexity of Haskell code varies greatly. The author of this block is dealing with an abstract topic, resulting in somewhat arcane looking code (I am sure that after some refactoring it would read nicer). It is however very possible to write really easy to understand Haskell code by ignoring its more fancy features and sticking to the most used abstractions: Monads, Applicatives and Functors. They alone are enough to write great code, no category theory, effect library, type magic or whatever is needed. Simple, real-world Haskell exists, it is just not often blogged about.

Fair enough, I just disagree with the premise that heavily relying on the type system actually lets you think less hard about how to implement your code. In my experience, defining the types you'll use at module boundaries is the actual hardest part. The stuff in the middle is usually straightforward until you realize you need sub-modules, at which point you're defining module boundary types again.

A good type is like a heads up display about where you are in your implementation. Haskell types are often far away from being that, however.

Absolutely, and I have put a decent amount of time in to learning Haskell. But I've been imperative programming since 8 yo, and as much as I love Haskell I can't be saved from finding it hard to understand. I also find it unmemorable - I could get my head around that code if I tried but 2 weeks later I will forget.

I also find that code quite abstract, it looks to be solving some kind of problem that usually the language designer (if say you are in C#) would be solving. Haskell seems to be something that leaks it's mechanics into your code, where as C# keeps it for the most part nicely separated from your code, albeit with the effect of giving the programmer less power. No typeclasses etc.