People who already know what a monad is probably think this is a great example. I still have no clue.
This is an inside joke about people who write monad tutorials and think they've completely solved the issue by explaining that they're just like, for example, burritos: https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...
monad tutorials are monads
class Monad (MonadTutorial badAnalogy) where
return badAnalogy = MonadTutorial badAnalogy
(MonadTutorial badAnalogy) >>= attemptToExplain = attemptToExplain badAnalogy
attemptToExplain :: Analogy -> (MonadTutorial worseAnalogy)
attemptToExplain analogy = MonadTutorial (makeItWorse analogy)
A monad is a weird/unnecessary concept for a type that wraps another type (and makes certain guarantees). Like you can have a List<Int> so List is a monad type. There's also an "option" type in many languages (which is just a list of size 0 or 1), which is a monad.
Some people call futures monads.
But the real takeaway is that people pretend they want you to understand all this type stuff, but they don't, they want to make up new complicated words for obvious ideas that you already understand, so they can feel smart. Once you understand it they aren't "smarter" anymore, so they make sure to explain every weird term they made up with 5 other weird terms they made up and insisting that all this abstract theory is relevant to everybody when it's not.
The "(and makes certain guarantees)" is the important-and-not-unnecessary part, rather than a parenthetical.
A “type that wraps another type” describes some monads like List or Maybe but not other monads like the IO monad.
A monad is a type which support a particular pattern of function chaining.
A future forms a monad because if you have a future that returns a future that returns an X, then there's a standard transformation from that to a future that returns an X
I don't regret learning how monads work, on the type-theoretic level. With that, it becomes very clear what things like null / None and operations like foo?.bar actually try to represent, or what transformations you can expect to work on various collections (like map() and flatmap() or filter()), how futures and promises work and how to easily combine them (and why JS promises are almost but not exactly monads, and where it matters), and, for bonus points, what does the "semicolon operator", that is, statement sequence, does from the logical point of view.
Understanding how state and IO can be represented as monads, and thus what useState() and useEffect() do in React, was also a nice consequence.
But certainly you are free to dismiss this piece of theory, and think about all these things as separate and peculiar. It usually very well suffices
> for a type that wraps another type
I think you are very confidently wrong here. Monads are not about wrapping types, as evidenced by the IO monad. You cannot say that a type is "wrapped" by the input-output system of a computer any more than you can say that a keyboard contains all possible character strings.
I am sorry to say but your comment is a cliche that's existed for at least the 15 years I've been using Haskell, where someone who doesn't understand a concept shows up, decries it as being a hoax and just a bogus complication on top of something simple, and while doing that displays not understanding it in the slightest.
But this existed before Haskell too, people have been doing what you're doing on the topic of structural programming, memory safe languages, regular expressions, dynamic html, ... html in the first place, microkernels, linux, unix, personal computers, minicomputers, computers, typewriters, looms, and electricity.
A list is a monad, but not because it wraps another type. What you're describing is higher kinded types.
A monad is a specific variant of a higher kinded type whose primary property lies in the fact that its value can be "evolved" via a specific function application (usually known as the "bind" operation). This sounds confusing but it's really a simple concept: if you take a higher kinded type, you can think about the values within it as the data and the type itself as metadata or a context of some sort. For example, an int is a piece of data, but a `Maybe int` is the same data with the added context of it being possibly absent.
A monad is not the only higher kinded type. Probably the most familiar HKT to working programmers (even if they don't know it) is the functor, which is a type that can be mapped over (in the sense of map-filter-reduce). If you have a `Foo<A>`, you can apply a function to turn it into a `Foo<B>`. However, a limitation of the functor is that you can only affect the data at the individual item level, not the context as a whole, so if you put a list of five values in, you'll get a list of five values back.
If we want to affect the context as well, we instead need a type like the monad, where we can "bind" a function that takes the inner value and returns a whole new wrapper based on it.
Why is this useful? Well, it can express a lot of different things very neatly - for example, fallible computation. Let's say you have two functions that both return a Maybe monad. In a language with nulls, you'd likely have to do something like `a = foo(); if (a is null) return; b = bar(); if (b is null) return`, which is tedious and error prone. Monads lend themselves to composing such chains extremely well, so you can simply do `foo().and_then(_ => bar())` and in the end have a value that combines the result (success or failure) of both of those functions.
Null values = chains of null checks = monads! Futures = chains of callbacks = monads! Mutable state = chains of writes = monads! Sequential execution = chains of statements = monads! And so on and so forth. You can get pretty crazy with it, not that I would recommend it.
Monads seem complicated and scary because most mainstream programming languages don't have the necessary abstractions to talk about higher kinded types as its own thing, but in reality most programmers are using monads daily without even realizing.
It reads as a little ambiguous to me in your comment, so just to be clear:
A polymorphic type - "a type wrapping another type" - isn't the same thing as a higher-kinded types.
Higher-kinded types are what let you express, in the language, the very notion of "a type wrapping another type". A "List Int" is a type wrapping another type; a "Maybe Int" is another type wrapping another type; but we can also say that "List Int" and "Maybe Int" (and etc.) can be abstracted over as "Monad Int"s. Monad is a higher-kinded type because it's a type wrapping types wrapping another type.
> A monad is a weird/unnecessary concept.
No it isn't.
A monad is a simple and easy concept that make it possible to write generic code that works across a number of very common things in software. The Monad interface is simple, and of immense practical utility.
There are only two things that are difficult about the concept:
1. The interface is so simple that it's hard to understand the purpose of it when you are looking at the interface disconnected from the concrete concepts that it abstracts over.
2. The interface was based on category theory concepts and created by people that have strong intuitions about category theory, so there is a lot of text floating around that presumes that background.
The essential thing here is that you don't need to know any of this in order to make use of the Monad interface or the generic code written against that interface.
> they want to make up new complicated words for obvious ideas that you already understand, so they can feel smart
> insisting that all this abstract theory is relevant to everybody when it's not.
Where is all of this bitterness coming from, my guy?
I like reading the comments on monad descriptions looking for all the ones that declare the wrongness with this one but either offer no further clarification, or offer a similarly useless and confusing description...then I look for the comments under those.
They become like beautiful fractal trees with branches upon branches of people giving alternate examples and then comments refuting those.
I'm pretty sure at this point this sort of meta-in-joke art form is what a monad is.
It's almost as good as the old "time to crate" way of measuring first person shooters.
It's a type of burrito
It's an endotaco in the category of fast food, what's the problem?
monad means a datastructure that implements flatmap.
I don't think that's a super helpful description, because probably most people wouldn't call IO a datastructure.
Monad means a function composition where you can program what happens when inner function gives its result as argument to the outer function.
I'll try to explain it. The article used F#, but I'll explain using Haskell, and first I'll explain dome Haskell notation, because I learned it while learning Haskell.
In Haskell, you have types. Concrete types have names that start with an uppercase letter, and generic types have lowercase letters.
inc :: Int -> Int
inc x = x + 1
not :: Bool -> Bool
not True = False
not False = True
-- id returns whatever it's given unchanged,
-- no matter the type.
id :: a -> a
id x = x
data IntOrChar = AnInt Int | AChar Char
-- Increment it if it's an Int, otherwise leave it
f :: IntOrChar -> IntOrChar
f (AnInt n) = AnInt (n + 1)
f (AChar c) = AChar c
You can have generic data types in the definition of a data tyñe and still add those tags. Generic type parameters are lowercase, just like in functions.
data Maybe a = Nothing | Just a
someFn :: Maybe Int -> Maybe Int
someFn :: Maybe a -> Maybe a
data Tree a = Leaf a | Branch a (Tree a) (Tree a)
someFn :: t a -> t a
In Haskell, Monad is basically an interface where it implements two functions: the infix function ">>=" and the function "return". The interface looks like this:
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
return :: a -> m a
Here's how you could write the Monad instance for Maybe:
instance Monad Maybe where
return :: a -> Maybe a
return x = Just x
(>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b
maybeX >>= f = case maybeX of
Nothing -> Nothing
Just x -> f x
instance Monad [] where
return :: a -> [a]
return x = [x]
(>>=) :: [a] -> (a -> [b]) -> [b]
xs >>= f = concatMap f xs[dead]
My Haskell is rusty—what does this line do?
type Burrito = Meat option * Ingredient list
Do lowercase `option` and `list` somehow specify `Option` and `List` types?
I think this is F#, not Haskell. '*' creates a product type, pretty sure it's a tuple in this case. "Meat option" is an alternative syntax for "Option<Meat>" and "Ingredient list" is a linked list of Ingredients
Looks more like F# (or something ML-y) than Haskell.
Yep, tuple or "product type."
Yep, in F# type annotations can be either in prefix style `List<T>` or postfix style `T list`.
[dead]
You are meant to feel it. Just: it does whatever is helpful.
https://blog.plover.com/prog/burritos.html
(Same concept, from 2009)
This is literally, not figuratively, true.
There's a lot of monads in our lives: puzzels, baking, stories, symphonies, paintings, and projects.
No one who cooks, cooks like this. So, no, a burrito is not a monad, unless you are performing Catholic Mass and the burrito is sth sth, in which case you have more words to write and I while I believe you can write those words, the words are not interesting. That it why I am saying your analogy is not interesting, and I think you were just attracted to burritos because they can hold.. anything? Even though that's not the path you went down?
Have you ever been to a burrito stand? Maybe a Chipotle restaurant? Literally the person assembling a burrito starts with tortilla and they add your meat and ingredients to it. The ingredients come from an array of pans at the counter (aka an enum of choices), and you (the consumer of said burrito) tell the maker what you want a series of "add this" type statements.
I get that cooking is necessary to prepare the ingredients, but once the ingredients are all individually prepared, the cooking is irrelevant to making them into burritos.
> You see, in addition to space burritos (if you've heard the rumors), monads are like onions. Allow me to demonstrate with a common situation.
Another mention of monads and burritos.
[0]: https://mostly-adequate.gitbook.io/mostly-adequate-guide/ch0...
The thing that has stuck with me about monads is that operations which you can chain like
// Python
new_foo = foo.bar().baz()
Work as / can be defined as monads, if you get a Foo out of each of them. This at least gives me something practical to hang the concept on.
Relegating "tortilla" to one word with no options is a travesty it's the most important part of my California Burritos from Juanitas.
Please do see yourself out mr, I can't have multiple meats
I assume that
let tortilla = returnBurrito (Some Veggie, [])
return Burrito
Also somewhat familiar with FP but not this specific language (guessing Haskell?), is the `>==` operator essentially a "pipe" operator?
This is F#. >== is a bind operator, but it's not built into the language, so it's defined as a custom operator here. |> is a pipe
`returnBurrito` is defined above it.
`return` is a specific function of a Monad, and it is not used like the keyword "return" in other imperative languages.
It's in jest, but I find a simple example like this to be very helpful.
Would have gone a long way to me understanding Monads, rather than some esoteric mathematical symbols.
Honestly, I still don't get it. Which part is the monad? What's the example showing?
The monad is the primitive/function that represents (VALUE or NULL), or in this case (CHICKEN or BEEF or ...). In this example, the ingredients and the burrito itself are also monads.
If you type-check your Python/JS/Ruby code, monads are a functional-style solution to get rid of that code (functional programmers don't like type-checking).
That's my simplest explanation at least!
Which symbol or identifier in the code is the monad?
In the code example, it'd be `Burrito` along with the `>>=` operator and `return` function. In Haskell, Monad is the type class (more or less an Interface) that specifies the types of those functions, so anything that implements Monad is said to be "a monad". F# does not have type classes, so there's not one single thing to point to in that code as a monad, only the interface being implemented as a whole.
The monad is none of the identifiers. If you combine the definitions you get a type with an interface equivalent to the monad and some floof methods (like the mission burrito starter, that's there just for convenience).
type Burrito is a monad, because the functions >>= and returnBurrito are defined. Any type for which those two functions are defined is a monad.
The Burrito type is the monad.
type Burrito = Meat option \* Ingredient list
let (>>=) burrito f =
match burrito with
| Some meat, ingredients -> f (Some meat, ingredients)
| None, _ -> None, []
let returnBurrito (meat, ingredients) = meat, ingredientsMonads are just function chaining worshiped in the holy language of category theory.
You have an array of state, and you can call a method on it that returns a new array of state, that you can call a method on, that returns a new array of state, etc. And that concept of doing state -> function call -> state is the holy Monad.
A JS pleb would write instead:
burrito = (new Tortilla()).addMeat(Chicken).addMissionBurritoIngredients().holdThe(Cheese)
No one would be confused about what was going on, and it would be basically the same thing.
Yes. But perhaps a syntax around the type of the return object to match with the next function.
While it is just functions. To say, it's just functions all the way down, doesn't help you talk about them.
Could say that math is all functions, and having some language to discuss that subject is maybe more the purpose of the monad.
Kind of like if you were to say to a math student, just go study functions, no need for any school or language to describe what is happening.
But yes, category theory is a bit heavy handed to a programmer just needing to chain some functions.
Maybe the problem is such a vast gulf between the junior dev just needing to know how to chain some things, and the category mathematician that has never coded. Yet they are circling around the same subject.
Ok Haskell programmers, I love you guys but this has now gone too far and I am officially intervening. The rest of the programming community and I are all super worried about what all this Haskell is doing for your health. Please stop before it's too late! Perhaps even touch grass, as drastic as I know that sounds.
The code is F#, not Haskell.
Oh, you think THIS is too far?
Not this shit again. How much can be said about a trivial algebraic concept with 2 laws and 3 operations?
This is my favourite comment on YCombinator and I had to reply to get a reminder.
I guess you meant 2 operations and 3 laws?
See? You knew it :3
I'm gettin it now! :)
Because grokking monads at some deep philosophical level is like "compiling the kernel" or "editing XF86Config": some mythically arcane thing you have to do that "only PhDs can understand" and hence is a good enough reason to avoid the thing it's a part of.
Monads are a design pattern, albeit not one in the Gang of Four tradition, and it's concrete enough to be expressible in Haskell's type system. Learn the operations and laws, study some code involving List or IO to see how it's used, and get to work. No big deal.
They aren't a design pattern, they are an abstract algebraic concept with two trivial operations (pure/flatmap) and three trivial laws (right identity, left identity, associativity).
Yes, Monads are about as difficult as compiling a kernel (run `make`).
Monad is mad