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.

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.

> Haskell is much more cognitively demanding than other languages from my experience

How?

I think Haskell code can be overcomplicated sometimes, but that's not mandatory.

If you have internalized the concepts Haskell is built on (to the point that you don't have to think about them), then Haskell can be as simple as any other language, maybe even simpler. But if you have to still have to think about the underlying concepts, Haskell probably is more cognitively demanding.

That's exactly the point, yes. People just have to properly learn the language.

I'm not sure it's that simple. I suspect (but cannot prove) that some people are naturally procedural thinkers, and others are naturally functional thinkers. Haskell just makes sense to some people - and not to others. To say they "just have to properly learn the language"... I could say the same about you and C.

Assuming I'm right, can the naturally procedural thinkers really learn to use Haskell? Probably yes, at least most of them. Will it ever be as easy to them as procedural programming? Probably not. What will that "not as easy" look like? Greater cognitive load.

I am aware that all of this depends on my opening assumption being correct...

That's an interesting assumption.

It might be true to a degree, yet I reckon the problem lies in CS teaching. A vast majority of programmers seem to start with imperative languages, hence they are more familiar with the procedural paradigm, and when they encounter functional code it seems alien and difficult to work with.

That's why I wrote people “just have to properly learn” functional languages. But your hypothesis is probably true as well.