So let's talk about monads.

Is this a subreddit or a selfhelp group?

Monad is just an interface that happens to be useful in many seemingly unrelated area.

It’s just an interface, similar to ICollection in Java or Iterator trait in Rust.

From a programmer point of view.

Functors and Monads For People Who Have Read Too Many "Tutorials"

"I'm mad about not understanding a monad pattern, and you can too!"

I have think it like this all this time.

I'm a pure mathematician, but it was some kind of hard.

I mean, as mathematician I have done plenty of times the "In math you don't understand things. You just get used to them". So it was just easy to don't ask what a monad is. The real problem begins to me when I come the "how do you use this thing" part.

Even with all the explications, examples and more, i just end implementing State monad in python three times before I finally really understand that State monad+ Reader monad is a way to do a pure access to variables that regularly you do by impure global variables. Even various examples mentioned it but I didn't understand since they didn't put a it in that terms.

So I became to think: What if I do a "let's use python as pure language and use it to explain why FP works like it does" blog entry.

I did some examples and then I began to understand even better how FP works by myself XD

So I never did the blog entry, but maybe some day I could make it and add it to the "how monads are like burritos" list of tutorials XD

My position is that you shouldn't ever teach monads or mention the word "monad" to anyone who isn't trying to learn (or already understands) Haskell-style purely functional programming (which can be done in impure languages, too). And even if they are, it should be mentioned only after they grasp types, parametric polymorphism, higher-order functions etc.

Sometimes other programmers will also encounter monad or monad-like instances (like a type for building cooperatively concurrent computations or the option/result type), but usually they will work with one of them at a time, and in this situation there is no point in mentioning monads.

you need to implement monads in an imperative language, and you need to talk about them in imperative terms.

Monads are purely functional (some use impure stuff behind the scenes, usually as an optimization), it wouldn't make sense to add imperative features such as loops/structured control flow or mutation to any explanation of monads. So you are talking just about syntax (in practice adding a few returns, commas, and various kinds of brackets :)?

When you look up monads, you find Haskell code because Haskell is one of the rare languages with higher-kinded types. A Monad is a family of types, and so expressing it usually requires higher-kinded types. You cannot reify Monad as a construct into Java or C# or TypeScript or Go.

Monad isn't anti-"imperative" any more than Comparable or Iterable is. The reason you cannot implement a Monad in Java is not that Java is imperative/not-functional, but that Java lacks higher kinded types. Ditto C#, TypeScript, Go.

You can implement monads in these languages (e.g., Option<T>, List<T>, ...) but you cannot reify the claim that they are monads, nor can you write code that acts generically on an unknown monad. This makes it very hard to communicate why this "pattern" of defining generic types with a flatMap is "interesting" or "important" without using Haskell.

As has been mentioned by other commenters, you could define Monad in Java with four lines of code (Though I would use less opaque names like box and flatMap), if only Java were to support higher-kinded types. But it doesn't, which is why almost all explanations use a "obtuse" language like Haskell or Scala.

Asking unironically: Do you speak Java? Does this help at all?

interface Monad<M> {
    <A> M<A> pure(A a);
    <A, B> M<B> bind(M<A> ma, Function<A, M<B> f);
}

static <A> M<A> join(Monad<M> m, M<M<A>> mma) {
    return m.bind(mma, ma -> ma);
}

static <A, B> M<B> fmap(Monad<M> m, M<A> ma, Function<A, B> f) {
    return m.bind(ma, a -> m.pure(f(a));
}

static <A, B> M<List<B>> mapM(Monad<M> m, ImmutableList<A> as, Function<A, M<B>> f) {
    switch (as.uncons()) {
        case Optional.empty():
            return m.pure(ImmutableList.empty());
        case Optional.of(cell):
            return m.bind(mapM(m, cell.tail, f), bs -> fmap(m, f(cell.head), b -> ImmutableList.cons(b, bs)));
    }
}

So, from the first paragraph, I see criticism of explanations in imperative vs functional, but the evidence you present supports more of a "how to teach good" flavor of specific/example/concrete vs abstract overarching pattern rather than the paradigms.

So, I wonder if it would be just as well to teach at the level of learning-by-example first. Specifically, "wow, I have a bunch of functions that take values and produce maybes, but I have to unwrap, do case analysis, and Nothing check each time I plug them together. There must be a better way?" An then picking your other favorite type constructors to do this with (that can be unwrapped by the user so rip IO).

This also helps put aside the pure/bind problem by letting you pick good names for each type constructor as you are teaching. e.g. for Maybe `pure` is `Just` and `bind` can be `ifSomething` or `ifNotNothing` or whatever you like. For Either `pure` is `Right` and `bind` is `ifRight`.

It seems like this would fit just as well in an imperative language (using mutation for intermediate steps) or a functional one (using let-bindings for intermediate computations).

W.R.T. the second paragraph, the problem I find is that when the learner approaches the topic, we go (at least in a Haskell point of view): "well before you can learn monads, we need to teach you typeclasses." because that is the common practice. You can see all the posts about Java not having higher-kinded types/generics kinda falling for this trap.

So, just don't? like, just put the method overloading, type-class inheritance, and do-notation to the side for a while.
Honestly, the design pattern gets in the way while they are trying to learn specific types because learners think "wow, they should all behave the same if they have the same methods" and so then you have to make them un-learn that and say "no, the semantics are very different, the general algorithmic shape is just the same".

​

For the record, I taught this the wrong way. because how I understood it best was: Some data structures are good to map over, call that a Functor. When we map a curried function over a data structure, we get a data structure of functions, and sometimes we would like to "map" that again, but Functor isn't powerful enough, call that an Applicative. Sometimes we have data/value constructors we like to plug together and Functor and Applicative don't let us do that because we get `M (M a)` double wrappings, so we need a flatMap, that's a Monad. `pure/return` are^nice^default^constructors^don't^worry^about^it. So, I have a lot to learn, too, but I don't know if this is reeeeally an imperative vs functional problem unless you equate imperative with "plain, what-you-see-step-by-step-is-what-you-get" and functional as "abstraction-barrier-a-palooza", which seems to be the real problem addressed by this post.

Edit: I will address that the big problem with teaching this in Haskell vs an imperative language is IO. for IO, you kinda have to use the monadic interface to make things work because you can't crack the IO open and write it yourself. But, people like to print stuff while they learn. So, what can you do? I have no idea. Other than just gloss over it, play in the interpreter which is in the IO monad already but shhhhhh, and don't think about IO until you've made the leap from monads-by-hand to type classes

I gave a talk about the core idea behind the concept a few weeks ago and at least my colleagues liked it: https://youtu.be/tlXz3aKJ6mI

I've been studying Haskell for about the past ~6 months, so as someone who has struggled through learning about Monads I thought I would share my thoughts. First of all, https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ is highly relevant here (I suspect OP read this article since he mentioned the infamous "burrito" analogy) and it explains the issue of deficits in Monad explanations far better than I could.

Speaking from my experience as a learner and person who had used imperative languages pretty much exclusively before trying to learn Haskell, I'm not sure if imperative code would have helped me significantly in understanding Monads since as many posters have noted, Monads simply are not needed as heavily in most imperative languages as they are in a language like Haskell which tightly constrains side effects. And chances are, if you are concerned about understanding Monads you are learning Haskell, in which case understanding their usage case in this particular language is highly important.

I think when I was learning about Monads I got hung up on understanding what they are, which in Haskell is simply a family of higher-kinded types which have bind and return functions defined on them and satisfy certain algebraic laws. That's it. I don't think an implementation of a Monad interface in C++/Java/etc. would have helped at all since the Monad pattern is just not as prevalent in those languages. The core problem is, understanding what monads are does very little to help you understand why they exist and what is important about them.

For me, this was a consequence of having very little experience with functional code in general. An analogous situation would be if a person was learning an imperative language for the first time and they were introduced to the concept of the Iterator before they had much experience with code that did iteration or traversal over many different kinds of data structures. In that particular case, the Iterator interface would probably make very little sense, since they would be unfamiliar with the pattern that an iterator is abstracting over.

What really helped me in my understanding was learning about the different examples of Monads and playing around with them and writing / re-writing their implementations until I really understood. Specifically, learning about Reader, Writer, State, and their derivatives was super helpful. Trying my hand at using Parsec and seeing a Parser monad in action was also a hugely beneficial thing for my understanding. Effectively, what finally got Monads to click for me was just trying to use them a lot until I saw the pattern and started to gain a bit of intuition.

There are many applications of Monads which I have yet to learn about and I still feel like I am just starting out on my Haskell journey, but I think I am now approaching the topic of Monads in a better way. I am not overly concerned about what Monads are any more than I am concerned about what iterators are in an imperative language. What is more important is what the particular implementation of the Monad is doing and what features it offers.

Anyhow, thanks for reading - I've been thinking about this topic for awhile and this finally presented an opportunity for me to share my thoughts

My main problem with Monads (along with Functors and what have you) is that I can’t get a grasp of exactly which part is the monad.

A list is just an ordered collection of items, a dictionary a mapping from keys to values. In neither of these cases the procedures for manipulating the structure is clearly not part of the structure. But for a Functor, which part is the functor? Is it the abstract idea of applying map? Same goes for Monads.

I understand your frustration — the ways in which monads are introduced in virtually every text, tutorial, and blog post are abjectly (if not objectively) terrible and, as can be seen anytime an author drifts off into the category theoretical aspects, too often lie somewhere on the spectrum of sadomasochism — but can I ask you to explain precisely what path has brought you to monads and why you feel the pressure to understand them?

I wonder if it’s at all like mine, and you’ve — perhaps prematurely — decided you need to learn Haskell?

[deleted]

I’ve made tutorial videos and conference talks about introductory fp including monads and applicatives. I have two approaches depending on the audience. For imperative programmers interested in fp I usually begin with pure functions and how to compose them, what their benefits are. Then I show real life functions that have impure effects. Then I introduce functor and map, applicative and ap, monad and flatmap, not necessarily named as such, to show how you regain the ability to compose functions and have referential transparency when you use these structures and type classes. For some audiences I use the names and link them off to deeper theory. I also made a video that starts with basic category theory and explains function composition and then kleisli composition in diagrams and then in scala which is, imho, a great way to grasp what a monad is used for in fp and its link category theory. I don’t think either of these is the perfect way to teach monads but it shows that there are multiple ways, and you should tailor to the audience. Ultimately there are people that want both.

I recently learned enough Haskell to write practical code, and I completely agree that it is often taught badly. That said, I really love Haskell and wish for more people to love it too.

The thing that was really new to me was the concept of wrapper types. (Or "higher-kinded types" to use a term nobody understands). Imperative programmers have tons of experience with the most fundamental of wrapper types: lists. You can think of List as a type you can wrap around any other type. So you have a List of Ints, List of Strings, list of lists, whatever you want.

The Haskell people are great at noticing common patterns among wrapper types and abstracting them into type classes. Then they give the type classes weird confusing names.

Some fun Haskell examples:

Monoids - Wrapper types than can be empty, and concatenated together (Example: lists can be empty, and can be concatenated. Lists are in the Monoid type class)

Functors - Wrapper types that you can unwrap, do something to their contents, then rewrap (Example: think of iterating through a list and doing something with each element to create a new list. Lists are in the Functor type class)

Applicatives - Wrapper types that can contain functions to apply to other wrapper types. This is where things get weird and Haskell-y. You need to have the concept that functions can be considered values. Haskell is big on this, but many other languages have have it too. (Example: you have a list of functions, and a list of values, you can combine them by applying all the functions in the first list to all the values in the second list, to get one big list in return. Lists are in the Applicative type class)

Monads - Wrapper types that can be sequenced together. Functions that take a plain value and return a value wrapped in these types can be linked together in a chain. (Example: You have two functions that take a value and return a list. You can sequence them together by taking every value in the list resulting from the first function and feeding it into the second function. At the end, you get a big list. Lists are in the Monad type class)

It turns out that many, many things in programming follow the pattern described by the Monad type class. Haskell guys just noticed this and tried to make the language abstract enough that it's meaningful to talk about them. Most other languages have specific implementations of how to sequence things together, so it doesn't help you know that they're following a Monadic pattern.

How do you describe the difference between red and green to someone who was born blind? How do you describe the meaning of the first word to that?

Many people never understand numbers, like the basic things. People freak out when they realize that 0.99999... == 1.

Many people never understand Monads. And that's because nothing is like Monads. You can describe some things in terms of Monads, but never Monad in terms of those things. It's something so simple and basic and trivial that it paradoxically becomes ineffable.

A Monad is any type M<?> where there's function (T) -> M<T> for any T and there's one that's (M<T>, Fn(T)->M<U>)->M<U> for any T and U. The second function could also be a method for any M<T> taking only the function.

That's it. There's nothing else. Why does that matter? Well try explaining to the always-blind kid why the difference between red and green matters. Like blind people somehow do it without colors, so why does it matter they are different? Try explaining it to an alien race that can't see light. This is where it gets complicated.

And to counter your point. Imperative programmers need to swallow their pride and realize there's many ways to see the same thing. If you define yourself an "imperative programmer" you are, by definition, someone who chooses to code badly. Not always, but sometimes. It's unavoidable, if all you have is a hammer, sometimes you will nail a screw in and ruin the board and screw. You can talk and write English perfectly well without ever using a word that has the letter e, but sometimes you'll struggle and things will be very complicated. It's perfectly fine as a personal choice, but if you want to call yourself a professional writer, you should be capable of using the letter e, even if you choose not to.

So I expect coders to learn and think in more ways. To realize that imperative programming is not "a thing", it's a weak metaphor you use to begin. Others use "functional programming". But really there's just ways to describe a problem and its computational solution, and they're all valid and work together. I'd expect programmers to learn functional programming, well enough to understand Monads, and Lenses, and Recursive Schemes. I also expect them to learn OOP, and patterns, and SOLID principles. And have the realization that you can implement Functors as Visitors that happen to return a new copy of the object they transformed, and that with this you can implement recursive schemes and describe transformations of the internals of objects in a way that is still very much tell don't ask. I expect people to learn about imperative programming, and realize the pragmatic way in which computers work. I mean there's solid Javascript tutorials for Monads in Javascript but really they're just as hard to "get".

And yes, this also means that things like Monads are actually very hard to understand. Not because they are complicated things, but because they require a lot of context, and abilities, and skills before they start making sense. You can kind of explain it, but it doesn't matter. The biggest sin is that people don't realize that, without certain background and context, you can't quite get some things. And it's not just with Monads. See how we teach trigonometry, suddenly shapes and formulas appear, and sin is really important, but most kids won't get an intuition. And many people will tell: you need to teach trigonometry like this! You should see things the way the kids do, look at their cultural background! But maybe the thing is that without map-making classes, drawing classes, etc. you just never get the necessary knowledge to even begin getting what the hell is the point of a circle and how is it not triangles, but we still use pi for both and why does any of this matter at all?