Assuming you mean iterators in other languages, I have seen folks bit by iterators supporting the "member" functions. That said, agreed that standard use is mostly fine.

The problem with monads, in this regard, is folks try and bend everything to them. I've seen similar with "everything can be iterated" before, and it ended as poorly as you might expect.

The basic trap comes down to the fact that many of us (yes, I'm projecting), really only understand basic algebra as defined with addition and multiplication. But a basic understanding doesn't help you see how that will abstract over working with other real life things. And as soon as you have to start dealing with non-transitive and non-associative things, the basic understanding can hurt.

>Monads are defined by their operations (flatMap/bind, unit)

This is why everyones intuition screws up. It's better to explain monads in terms of the Kliesli operator (>=>). Monads like functions in functional programming are about composition and the explanation should center around that.

The right intuition about monads is that they are higher level functions that like regular functions can compose.

Bind by itself feels weird and sort of pointless for a newcomer as he usually thinks why does this sort of strangely specific operation need to be abstracted behind a name "monad"?

Is there a tutorial that uses this approach?

your in luck I wrote one which no one read in a reply:

https://news.ycombinator.com/item?id=37427499

I hope it helps. If not then I'm utterly wrong.

The problem with monads is just the words. "bind" in particular is a bad term!

It make sense in some contexts: it binds the value produced by the monad to a new name. For example, it binds (or "assigns") the value read from a file to the variable x.

I agree that `flatMap` is clearer when manipulating lists, which is probably a better first approach than the IO monad. However `flatMap` would sound weird for IO monad, I think.

What I find confusing is using the do notation for monads with very different meaning. Code looks the same but it does something totally different!

I wonder if putting the Monad interface ("typeclass") front and center in Haskell is such a good idea. Kinda feels like premature abstraction. We should use descriptive names instead of opaque abstractions.

...or maybe I haven't seen the light yet.

I'm using Scala syntax here... If I have:

  val a = IO(42)
  def f(n: Int) = IO(n)

And I use map, then I get:

  val r: IO[IO[Int]] = a.map(f)

Which we don't want... the solution is to flatten it. This can be done with flatten, or flatMap:

  a.map(f).flatten
  a.flatMap(f)

Both produce IO[Int], and this makes sense to me using any monad. By contrast, bind means nothing to me.