Imagine if, when you first started programming, and you wanted to do something with numbers, and you found out that in your programming language, the way you did that was to use something they called "Integers" (I know, right? ridiculous). So you google "Integers" and you find https://en.wikipedia.org/wiki/Integer, which helpfully tells you
"In elementary school teaching, integers are often intuitively defined as the disjoint union of the (positive) natural numbers, the singleton set whose only element is zero, and the negations of natural numbers."[1]
And you get the impression that to add a couple of numbers together you're actually going to have to understand cardinality and group theory and so on.
That's kind of where we are with monads, with the insistence on the academic language.
Though it does suggest that I could have fun by persuading beginning programmers that to really grok text processing they need to start off with a thorough grounding in string theory.
[1] I checked with my son, who goes to elementary school. I'm not sure he even knows what a disjoint union is. I'll have to have words with the teacher.
We have to do better at finding a way to teach this stuff.
https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotati...
IME, that's not at all true; most of the theory-heavy sources I've seen are explicitly framed as alternatives to the large body of intuitionist tutorials that avoid theory almost entirely, focusing on a few popular applications (usually, collections and IO.)
"In mathematics, the quaternions are a number system that extends the complex numbers."
Naturals are a subset of integers. Integers are a subset of rationals. Rational are a subset of reals. Reals are a subset of complex numbers. The latter are a subset of quaternions. It's not difficult to construct each number system. If you look inside any undergrad math textbook, you'll find exact same writing style showcased in the Wikipedia article on quaternions.
[0] https://news.ycombinator.com/user?id=coolsunglasses [1] http://haskellbook.com/
What you'll usually see people insist is to describe monads by their operations, rather than through metaphor. That is, a monad is a type parametrized by some other type, with the following two functions:
1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b
such that three laws hold:
a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)
For monads in Haskell, this is the technically correct definition.
That said, most people will tell you the best way to understand monads is to look at a few basic monad instance implementations (Maybe, Either a) and program with them, slowly learning new instances.
That is, a monad is a type parametrized by some other type, with the following two functions:
1) return :: a -> m a
2) (>>=) :: m a -> (a -> m b) -> m b
a) return x >>= f == f x
b) m >>= return == m
c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)> "just a monoid in the category of endofunctors"
In fact, even among people who DO know the category theory necessary to understand this expression it's considered a very obtuse and useless explanation. Especially in the context of Haskell.
As for good readable introductions, I consider Wadler's paper "Monads for Functional Programming" to actually be a pretty good introduction. Another good intro is "You Could Have Invented Monads! (And Maybe You Already Have.)" http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...