> There are other problems that make Haskell hard to work with.

What are the biggest or most important ones in your opinion?

I'm not who you asked but I think the clearest example is lazy evaluation. Anecdotally speaking as someone who's helped teach a few classes in Haskell, students often have problems with laziness until they really adapt to the functional paradigm, and even then continue to have some problems.

The other common problem I see is not actually a Haskell problem but merely a problem Haskell exacerbates: many students fail to think through their types prior to starting an implementation. I frequently had students in office hours trying to force their way through a problem and when questioned about the types were unable to reason at the type level intuitively. I suspect this reflects larger problems in my university's undergraduate program, but I figured I'd comment on it anyway.

I can testify, to my embarrassment, to the same experience.

Sure, it was just an off the cuff example. And while I agree that monads are not horrible by any means I think you are oversimplifying a bit. Monad transformers, the mtl library, ect. all exist after all... Even if using monads is relatively painless I wouldn't say that it's easier than using a language that allows you to freely execute side effects wherever for programs that are highly interactive.

Haskell does let you freely execute side effects. It just asks you to label any function that does so. People get tripped up by it because it's different, but in practice, it's absolutely trivial.

`IO` is all you need if you want to freely execute side effects wherever. `mtl` and friends are for when you want to restrict which effects are available where.

Would there be so many ineffective tutorials and bad analogies if having to use monads really wasn't a problem?

Surely people never overcomplicate simple things, right?

:)

Weirdly once i stopped trying to understand what a monad was, i had no problem using them.

The problem with monads is that they’re a term from abstract algebra. Haskell’s documentation talks about them from that perspective (including monad laws), which makes them quite natural for anyone who’s studied some abstract algebra in university.

Unfortunately, most programmers trying to learn Haskell have not taken any abstract algebra courses, so these definitions and laws are deemed insufficient. Regular people want to know the exact nature of a thing — not just a list of mathematical properties that hold — and so they insist that there must be something more. But there’s nothing there!

This is FUD. You don't need to have studied abstract algebra to understand the monad laws. Basic high school maths is more then sufficient. It really surprises and concerns me that so many developers seem frightened and wary of mathematics and logic. It used to be called "software engineering".

> This is FUD

I think chongli is actually in agreement with you

The reason that there are so many tutorials and analogies is because monads are relatively easy to understand, but unfamiliar, and they allow you to do a bunch of math (which you don’t have to do). Not hard enough to cause Haskell programmers any problems.