As for calling them strategies… if we called them that it would make learning and understanding the intermediate and advanced concepts significantly less accessible and more difficult. We should call things what they are.
As for calling them strategies… if we called them that it would make learning and understanding the intermediate and advanced concepts significantly less accessible and more difficult. We should call things what they are.
Names don't need to be metaphorical. The purpose of a name is not to teach you what the thing is. For that, you should have a proper explanation from someone who knows. Names have a different, very important purpose: uniquely specifying the thing being named. "Monad" does that very effectively.
The reason could be that the term "monad" comes from category theory, and that is a topic not everybody is too familiar with...
Sure - I wasn't seriously suggesting we rename them, just that in my personal experience, newcomers get scared off seemingly by the name alone before ever actually finding anything out about them. A friendlier name may avoid this for newcomers. It definitely wouldn't be worth it for more advanced practitioners where referring to them exactly and in the context of their category theory roots is much more useful than friendliness.
(For what it's worth, you may not have been serious about renaming monads, but many others have seriously proposed it. In most languages other than Haskell they've been successful.)
If people want to learn about monads is up to them and I don't have any skin in the game, but I hear a lot of people complaining that monads are so difficult to understand or use and I guess I was really just observing, in a roundabout way, that I feel a lot of that is down to monads appearing more complicated or scary than they are and that people are put off by it, kind of how people are put off Lisp's due to the parentheses.
Its an abstraction and abstractions are hard. In away, its similar to why beginners tend to have trouble with recursion (if you try to understand a recursive program by stepping through without using abstractions like preconditions and postconditions)