>For some reason Haskell users try to make things sounds as academic as possible.

Probably because Haskell ended up being the language for academics. If you want to do programming language research in an ML-type language use Haskell. If you want to make a product, use OCaml. Not entirely true, but pretty close.

>So bind is flat map in other languages.

In the case of a List, yes, but there are other datastructures that implement Monad. This type of thing happens a fair amount in Haskell. It is not that uncommon to see code like:

    instance Monad List where
        (>>=) = flatMap

That is to say, the implementation of the interface is just another function that has a more domain specific name.

There are other monads with a bind that cannot be understood as flatMap.

For example, the Maybe datatype is Haskell's version of Optional. For example, if a variable is of type `Maybe t`, it either contains a single value of type t, or no value. It is common to use Maybe without using it as a monad. However, Maybe does implement the Monad interface. In this case, bind is defined as follows:

    x.bind(f) =
      if (x.hasValue()) then { return Just(f(x.value)) }
      else { return Nothing() }

where Just and Nothing are two constructors of Maybe. If we view 'no value' as analogous to null, then this bind function is null propogation.

Bind is flatmap in the case of lists. Bind is way more generic than just the list monad, and the name "flatmap" doesn't apply to most other monads -- most of which are not List.

Yes, bind is just flatMap.

Various people seem to be arguing that "flatMap" only makes sense for Lists and similar containers, but I don't really see why. Yes, you have to broaden your notion of "flattening" to understand it, but I think that's a lot easier for people to learn than a "new" operation called "bind".

I've been using Scala for a while after learning Haskell first (and understanding monads), and I've noticed how much more easily people understand flatMap, even for e.g. Futures.

Bind is a great name. When you have a function that takes a monadic value of type `m a` (e.g. List[A_] in scala I think) it becomes convenient to program with lambda functions. For list comprehension, you can program like this (python notation now, since everyone reads it):

    bind(list_of_xs, lambda x:
    bind(list_of_ys, lambda y:
    return(x+y)))

That's a list comprehension. You bind the monadic values (list_of_xs) to element values (x). On lines 2 and 3, you can think of x as a bound variable that was assigned to one of the elements of list_of_xs on line 1. Then we "assign" y on line 2, and it's in scope on line 3. "Assign" would have also been a decent name for it. It's way more intuitive for me to think of those three lines as assigning/binding x and y to be summed together, rather than thinking of one flatmap of a lambda to flatmap of a final lambda to a function. The abstraction of variable binding just fits.