Though now that FP concepts are mainstream, I think there is a good case to offer some friendlier, more familiar names:
Functor -> Mappable
Applicative -> Pairable
Monad -> Thenable
[0]: https://softwareengineering.stackexchange.com/questions/2033...
I've been writing Haskell for over 5 years and to this day when I see <$>, <*>, >>= in my code I don't substitute English words for them.
mentalModel.update().
The query `python @` fails pretty hard though.
:info (>=>)Citation needed
Calling Functor "Mappable" and Monad "Thenable" doesn't really add much to understanding.
The best advice I ever got was that a Functor is `f` with a function `fmap :: (a -> b) -> f a -> f b` that follows its laws. Same goes for Monad. If it has the type signature & follows the laws, it's a Monad. That's the definition. No need for a cute analogy-oriented name like FlatMap-able or Then-able.
Once you do that, you realize that the way to understand these things is to play type tetris with highly-generic type signatures. You stop needing English/real-world analogies to understand them and instead use the type system to understand the world (the reverse of using "nice" names)
It works really well but it is a steep hill to climb. It helps to talk to others who have climbed it, and it helps to just grind on a project and use Monads without being an expert. You can go a long way just knowing how `do`, `traverse`/`mapM`, etc work and not having big Monad intuition.
Citation needed.