Programmer Humor

Of course!

In other words though, for those just starting their monad journey:

An endofunctor is a box. If you have a box of soup, and a function to turn soup into nuts, you can probably turn the box of soup into a box of nuts. You don’t have to write a new function for this, if the box can take your existing function and “apply” it to its contents.

Arrays are endofunctors, because they hold things, and you can use Array.map to turn an array of X into an array of Y.

Monoids are things you can add together. Integer plus integer equals integer, so ints are monoids. String plus string (concatenation) equals a longer string, so strings are monoids. Grocery lists are monoids.

Arrays are monoids!

Arrays are both endofunctors and monoids, so for everyone except category theory purists, they are monads.

Javascript promises hold things, and you can transform their contents with .then - so they are endofunctors. You can “add them together” with Promise.all (returning a new promise), so they are monoids. They are both monoids and endofunctors, so they are monads.

I’ve just upset all the category theorists, but in the context of programming, that’s all it is. It’s surprisingly simple once you get it, it’s just complicated names for simple features.

It's a pretty natural consequence of other languages simply not having a concept or word for the thing that we're trying to abstract over, so better names simply don't exist. I've yet to see anyone come up with a better name than "monad" for the concept. Same for monoids. We may as well use the names that come from math and are already used extensively rather than trying to invent some new name that would invariably be misleading anyway.

Every single programming language is chock full of jargon that is basically meaningless to anyone unfamiliar with it. It's really no different. The only difference is that monads are fundamentally an unfamiliar concept to many imperative programmers, particularly because programming in that style pretty much upends a basic assumption imperative programmers tend to have (namely, that the semantics of sequencing operations is a global, immutable property of programs).

I'm glad there is at least one serious answer on this thread.

In my experience they're only really in your face when you're doing things with side-effects, and at that point it's just a lobster trap that collects your non-functional code until you pass it to main. Maybe I'm just a lame Haskeller though.

That's not a monad, that's just typeclasses (also known as traits/interfaces/etc.).

If you're familiar with flat_map or and_then in Rust, you already get the basic idea of monads. Just imagine that instead of the ad-hoc implementations that Rust has to do (since it doesn't support higher-kinded data types), you could express it in a single trait. Then you can write code that generically works with any types that support flat_mapoperations (along with a couple of other requirements, like needing a From<T> impl, as well as abiding by some laws that are really only a concern for library authors).

If that sounds simple, it's because it is. It's mostly just that it just so happens that being able to write code in this fashion has some pretty significant implications. It essentially allows you to very strictly control the semantics of sequencing operations, while still giving you enough flexibility to enable many of the things you typically do in imperative programs. In a language like Haskell which is built on monads, it's a very powerful reasoning tool, much in the same way that purity in functions is a powerful reasoning tool. It allows us to do things like, say, represent async code blocks as first-class concepts requiring no special syntax (no async/await, etc.), because the monad interface allows us to dictate what it means to sequence async actions together (if you're curious to see what this looks like, here's a link to Haskell's Async type from the async library: https://hackage.haskell.org/package/async-2.2.4/docs/Control-Concurrent-Async.html#t:Async).