[bojo]

When we say "reduce programmer cognitive overload" we are usually talking about purity.

  f :: A -> B

There is nothing ambiguous about this function when considering application state and IO. You cannot call fireTheMissiles inside it, it performs no side effects. It simply takes an A and returns a B.

The headphone rule always comes to mind when talking about this. Typically developer productivity is killed when a developer is interrupted because they are trying to maintain a complete picture of time and space in their head. This problem is much less so with Haskell because you can just glance at the inputs and outputs of the function you were working on and get back on track immediately.

In the sense that you are implying, that the language itself is cognitively demanding, I would argue that is only a beginner problem. Once the core concepts are internalized it's actually very easy to use.

Where it gets hard and becomes a mental burden is when you start going off the map and looking into some of the more advanced concepts, like type level programming, which to date we haven't had to pay attention to or use on my team.

[risto1]

If you're talking about purity then I'd agree with that, but I'm talking about haskell as a language.

I'm definitely not a haskell beginner, and I know others who are definitely not beginners and they feel the same way.

I'm talking about the language as a whole. With all of the extensions available, there's plenty there for even seasoned haskellers to learn. Sure you can get used to anything, but I've found the more advanced type features, and higher kinded polymorphism, to make code and type errors harder to reason about. Sometimes type inference screws up in ways that makes it hard to figure out whats going on.