What the Heck Are Monads?!

Today, I'm going to take a deep dive into monads. They’re a well-known concept in functional programming languages like Haskell, but are they useful elsewhere? Stay tuned, and by the end of this video, you'll understand what monads are all about.

🔖 Chapters:
0:00 Intro
1:19 What is a monad?
1:41 Step 1: Understanding Functors
2:53 Step 2: Understanding Endofunctors
4:00 Why is Functor an Endofunctor?
6:22 Step 3: Understanding Monoids
7:15 Step 4: Monads as Monoids in the Category of Endofunctors
11:50 Maybe monad
19:12 Should we switch to monads?
20:36 Outro

#arjancodes #softwaredesign #python

[Pandajuice]

Whew, thank you for uploading this. I have a wedding to go to tonight and wasn't sure what to talk about with my fellow attendees. Now I do!

[gustavomezzovilla]

7:05 small correction: associativity means that x+(y+z) = (x+y)+z. What you've describe is commutativity (or the abelian property).

[blakasmurf]

I got kicked in the Monads once, boy was that painful!

[kodefood]

Finally someone who actually came close to explaining monads in a way that normal people can understand! I've only been waiting over a decade since Brian Beckman made the 'definitive' explanation that ended up confusing everybody.

[sigmundwong]

In general, when thinking about programming languages in terms of category theory, functions in the PL are considered morphisms, and types are the objects. Functors map one category into another category. Therefore, unless you're somehow departing the language altogether, you're only ever going to touch endofunctors. To be more precise a functor, is any type that is: 1) defined in terms of another type, 2) preserves functions between types (this is what "map" gives you), and 3) preserves identity functions. The initializer is NOT required for it to be a functor. That is, any functor F<> does not automatically give you a function T -> F<T> for any type T. The initializer is better thought of as a natural transformation from the identity functor to the functor in question.

[dankprole]

Any chance of a video on Generics? I have used them a bit in the past but i don't understand why you made the Monad depend on T at 8:49. I've never seen a good video on this topic.

[filippopisello]

Happy to see some more advanced content!

After being lost for about 18 minutes, it suddenly clicked how I could have used something like this instead of regular error handling on a project a couple of months back.

Cool to be reminded that there are alternative approaches out there!

Cool to be reminded in mind that there are more ways to do stuff!

[lucasyoungers]

This is a fantastic video, I have tried time and time again to understand monads, but this was the first video that really clicked. I like how you broke down the "monoid in the category of endofunctors" so thoroughly, that was a huge help.

[Piipolinoo]

haha, this one was magical and I didn't see it coming! Following along I was like "feels like this weird concept which I haven't fully understood when i was trying to get into Rust" - turns out it was and I finally got it now! so I've watched a python video about a thing I shouldn't do in python, learnt about rust and ended up a better programmer than i was before. That's why you're once of a kind on youtube! have my thumps up :)

[ryanfu]

Thanks a lot!! Really cool and clear explanation.
Just have a question.

Can we do early return when there is an exception in the bind chain?
like in this example

n: Maybe(double(n)))

Thanks!

[WalterVos]

Very nice to have you discussing an advanced topic again! Are you currently working in languages where monads do make sense?

[mattholden]

@ArjanCodes Very heady topic presented in an extraordinarily approachable way. I really liked seeing you turn maybe into a decorator. That gives me lots of ideas for my own home-grown functions. Thanks for another great tutorial.

[johnathanrhoades]

Video 3 on monads. Still working on the comprehension! Very well explained.

[JSDudeca]

Thanks for showing this. Best video on monads by far and great to see better pattern matching usecases. Lately I’ve been writing tools that return tuples (eg (ok:bool, val: int, reason:str) returned from tryParseInt ). This is a great use case for pattern matching logic in the caller.

[mrc]

Thanks, Arjan. As a Scala refugee, this was very useful to me. If someone in the Golang community can come up with an implementation, it'll be funny to see what they called it.

[evgeny]

Thank so much Arjan! I tried to understand Monads each time I got hyped on functional programming, but only this time I think I understood the idea of a monad and usecases. And actually it seems that I have already been using something like that for error handling with ts-result library that brings in this railway approach that you mention in the video

[KrishnaAddepalli]

Very nice explanation about Functors and Monads. Seems like you have broken the curse of the Monad!

[Yankzy]

Awesome you back on advanced stuff! You should do metaprogramming topics

[thomaseb]

good and informative video, i have a small nitpick, Maybe isn't really the typical exception handling mechanism, its more the null or none handling mechanism, and to this extent the Result<T, E> in rust would be the try except equivilant and Option<T> would be Maybe (synonymous)

monadic handling can be very useful even in languages its not implemented, it would come down to developer preference and style, i myself prefer monadic handling

[oreos_overdose]

Not necessarily a criticism, more of an observation but this seems leaps and bounds ahead in complexity with respect to most of the subjects of your other videos.