I don't consider Java to be statically typed. Sure, there's some compile-time type checking, but OOP is naturally dynamically typed. This is why you end up subverting the type system (I believe it's called "POJO") all over the place when you write Java.

To be pedantic about it, Java has two type systems. It has a bottom-up, mostly static, ALGOL-inspired type system with primitives and arrays (e.g. int, char[], double[][]) and a top-down, semi-dynamic type system for object types.

Maybe, but then the objective isn't so much 'use a static type system' as 'make Haskell palatable to a decent percentage of programmers'. I'm not saying it's impossible to do that, just that it's a different challenge and needs to be understood for what it is.

I agree. What would you suggest?

The issue, I think, that Haskell has is not that the language is hard to use, but that the type signatures can be anywhere from obvious to counterintuitive and, to a beginner, horrifying. The issue is that the "best" (most general, most mathematically accurate) type signature isn't always the one that gels with what we want from it.

An example would be the Lens type signature. It takes some on-paper, figure-it-out work to understand why this is the right type signature. It's this Rank-2 beast:

    type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t

When most people would find it more intuitive to have something like this:

    type Lensish s t a b = L {get :: s -> a, set :: s -> b -> t}

Sometimes in Haskell we go for full generality and mathematical correctness, which is great, but also makes the language harder to understand.

Then there are the names. Personally, I don't find "monad" or "functor" to be that bad. They're new concepts that must be learned, but they're a lot easier (and more useful!) than OOP's 23 design patterns, most of which are horrible.