Brian Beckman: Don't fear the Monad

Cross posted from msdn's channel 9.
Functional programming is increasing in popularity these days given the inherent problems with shared mutable state that is rife in the imperative world. As we march on to a world of multi and many-core chipsets, software engineering must evolve to better equip software engineers with the tools to exploit the vast power of multiple core processors as it won't come for free as it did in the recent past which was predictably based on Moore's law.
Of course, learning new ways to think about programming semantics and code patterns are not always straight forward. For example, most imperative programmers (which include most of us who build software for a living...) are somewhat perplexed by the notion of functions as first class data structures that can be combined to create powerful and composable systems. Languages like Haskell are pure functional languages and require programmers to think in a different way, often in a precise mathematical fashion where composing and chaining functions is "the Way".
Dr. Brian Beckman, a Channel 9 celebrity, astrophysicist and senior software engineer thought it would be a very good idea to address the complexity of monads in an easy to understand way: a technical conversation at the whiteboard with yours truly for Channel 9.
This video interview is the result of Brian's idea that he can in fact remove the fear of monads from anybody who pays attention to his explanation. Of course, you can't just cover monads in a vacuum (category theory is not really addressed here) so the context is functional programming (Brian covers functions and composable functional structures (function chains) and of course monoids and then monads).
Tune in. There's a lot to learn here and only Brian can make monads easy to understand for the rest of us!

[@Collagenre]

Ten years from now, whenever I encounter any trouble in any aspect of life, I know I'll be hearing Brian Beckman's assertive yet comforting voice saying, "And w'e're still not scared. Nothing new here, this is stuff you already know. This isn't confusing; we're not scared."

[@MrEyee2]

+Collagenre Totally the best part of this talk!

[@Knigh7z]

reminds me of bob ross

[@thebestv00d00]

uuu

[@jungleb77]

I'm fortunate enough to get to work with Brian, he's just as great in person.

[@dawid_dahl]

Hahah, comment of the year. 😄

[@australai]

First few minutes: Setup for explaining Monads to "imperative-type" programmers. Connections to Lync and F#. Explains you don't need to understand category theory to grok monads. Analogy to learning processes for natural languages (e.g. French). 2:30 - "What the hell is functional programming?" 6:34 - Shared mutable state and functional programming 7:39 - Simulating shared mutable state with monads. Will explain Monads in terms of functions and monoids. 8:19 - Syntax for simple function and type declaration. How to say: "Function f takes an a and gives you a" 11:09 - Composing two functions 12:47 - Function application syntax 13:28 - Brackets for currying. Handling associativity 14:22 - Define "little circle". Simpler function composition 15:32 - Essence of monoid: Taking two things of same type: (function and function). Create new thing of same type 16:27 - Talk about usefulness. "This is THE WAY to build complexity" Controlling complexity. 17:38 - Explaining "simple" .. Simple == small 18:15 - Art of designing composable software. Build rich space of big software from simple building blocks. 19:12 - "THE WAY to do it" .. generic composability operator 20:01 - "The beauty of this" .. "discipline: put all function in type universe" 20:38 - "In the world of monoids" Clock example 21:08 - Monoid: Collection of things + a rule for combining them (rule obeys some rules) 22:53 - Monoids must follow associativity (grouping doesn't matter) 23:21 - Second rule: Special identity member (called: unit or zero) 23:59 - Special member is commutative, but other things don't have to be 25:27 - "Functions under composition form a monoid" 25:56 - Tangent about monoidal category 26:21 - "To be fully fluent in this language of function composition, all you need is the types to line up" 27:47 - Prove that function composition is associative (show that functions are in a monoid) 29:45 - Second rule (unit or zero) is the function: "id" 30:32 - "Functions under composition are a monoid" 30:39 - "What is a monad? ... almost the same as a monoid, but with a twist" 30:57 - "Enter the realm of functions that take a and return some transform of an a" 31:28 - "We don't have to be scared because we didn't do anything scary." 31:42 - Type notation. Type constructor 31:53 - "Every function in compositional universe will take an a and return some extra data (applied to a)" 32:18 - Explain compositionality with this new "M" 32:31 - Introduce lambda notation 34:32 - "We don't have to know what M of a does as long as it's the same type everywhere" 34:47 - "All we're really trying to do is bring the world of side effects under control with compositionality" 35:25 - Lync is a monad 36:14 - Introducing bind operator (he calls it shove). Allows composing monads. 39:41 - Type signature of bind 39:50 - "Where people get confused with monads... how I will un-confuse you" 40:43 - "These functions live in a monoid... these data live in a monad" 41:00 - For compositionality: We need extra data to do concurrency, IO, etc... data in monad 41:21 - "Bind is the guy that ensures our functions are compositional" 41:31 - "You have to design the bind" 43:11 - "Why on earth would anyone do this?" ... control complexity 43:24 - "You need to be able to create functions you can mix and match in any way" 44:20 - Design the "unit" (second monoid rule) Called: "return" 44:51 - Lync comparisons 45:47 - Concept review 46:41 - Create your own monad: one that does nothing but change type (identity monad) 47:12 - Lync practical use of monads 47:58 - "One query language that works for all these data types... looks like a miracle, but it's a monad" 48:35 - Chaining types 50:20 - Chaining types monoid example 52:05 - C# version. "Functional programming is a style that works in any programming language" 54:33 - Can't reverse type chain 56:33 - Good introduction to category theory 56:54 - Chaining types monad example 59:06 - Type of bracket/bind 1:01:00 - Invention of Lync: "I need this compositionality, how do I get it?" 1:02:08 - Why functional programming is a "hard sell" (computing history) 1:02:23 - "Bottom up" camp: close to hardware... C 1:02:44 - "Top down" crowd: start with the math and subtract abstraction as necessary... lambda calculus 1:03:22 - F# 1:04:10 - "You will encounter monads soon... coming at you like an 18-wheeler" Final summary

[@Autom_te]

For anyone confused he's refering to Erik Meijer and LINQ

[@LukeVanIn]

36:00 "Let me stop recording the whiteboard at a critical point, and rather focus on the speaker's ear."

[@TheGeneralCase]

It's because he's focused on the instructor's gonads and not his monads.

[@spiderstheythem]

i want to listen to this gentle wizard man explain everything to me for hours on end he has a very nice & comforting voice

[@ryanleemartin7758]

I've seen this a number of time over the last few years. The first time I saw it, I didn't know any functional programming and this made no sense but it was exiting to ponder. The second time it still didn't make sense but it was slightly less fuzzy after working with Linq. The third time I saw it it made a tiny bit of sense (the clock analogy was huge) because I had learned to pass and return functions to and from other functions in javascript. The fourth time I saw it, I was poking around with F# and monoids made sense but monads and bind were still beyond my grasp. After months of F# practice, I watched this again for the 5th time and light bulbs were firing and things were much clearer (still not entirely but I get it). The point I think I'm making is that you must DO functional programming even if you don't really get it. You must live in confusion and pain and slowly with persistence the light creeps in and a wonderful world emerges. This single talk is a gem to come back to again and again along the journey to functional programming. Thanks Charles and Brian!

[@Evan490BC]

There is this approach, "iterative refinement", let's call it, and there is the Tabula rasa approach: you need to completely "unlearn" imperative programming, in order to get functional programming.

[@michaelkohlhaas4427]

You're coming back to this video because it's a total mess!

[@ryanleemartin7758]

@@michaelkohlhaas4427 lol, fair enough

[@codeasone]

Truth

[@shukterhousejive]

Excellent talk from the bad guy from Half Life 2

[@egor.okhterov]

+Shukterhouse Jive It is interesing how google managed to show me how this bad guy looks like, by just googling "Half-Life 2 bad guy"...

[@oriontvv]

Lol. He knows all secrets with lambdas)

[@SongMachina]

and the symbol in Half Life is a lambda ... were they trying to warn us of the dangers of functional programming?

[@scitwi9164]

Conspiracy theory: They wrote "Half Life" in high-level functional programming language and cross-compiled down to imperative C to let the C compiler do the dirty job :q

[@robertstiffler1251]

SongMachina lambda is also the symbol for half life in physics

[@Denominus]

For future C# viewers, Task was implemented the same way with "await" as syntactic sugar for "bind". Task.ContinueWith(x => ....) is a synonym for Task.bind(fun x -> ....). This design is why functions returning Tasks are composable.

[@artist6000ish]

This is the problem with every video I've seen about monads. They all start with: 'We're going to do a better job at explaining monads than every other video on youtube.', but then proceed to make the same fundamental mistake. Instead this is what they should do: 1) show a concrete example of the problem sttement, in the language that the viewer already knows, 2) show the viewer what the typical way to solve the problem, in the way that the reader would likely solve the problem on their own, 3) now tell them what the downside is with their solution and finally 4) show the viewer how monads solves the same problem without the downside.

[@enricserrasanz7456]

feel free to make such video, I really enjoy the clarity of this guy and his explanation. BECAUSE NOT EVERYTHING CAN BE UNDERSTOOD WITHOUT UNDERSTANDING THE MATHS UNDERNEATH. Sorry

[@pol...]

This video makes monads pretty easy to understand.

[@ibiwan]

I agree. START with two examples and their solutions, then go back and present the logic, including how it applies to both examples. Why two? So we can see the parts that are example-specific and the parts that are in common between them. Include all the advanced math you like at this stage, because there is a concrete application in front of the viewer the whole time.

[@ibiwan]

VICTUALS

[@ibiwan]

THAT WAS AMAZING. I am in your eternal debt. Now I ACTUALLY know what a Monad is, and I know that I've been using them for nigh on a year, in the form of Promises

[@filiformis]

The only man on the planet that both understands what a monad is and can explain it.

[@JonasNgYF]

Watched this five or six years ago. Rewatched in its entirety just now. This video is great as the exposition is clear and we are led step by step to understand monads are just about function composition. Monads provide the constructs for composing functions that take “plain values” and return “monadic values”. It is just function composition with an extra bit of housekeeping that takes a value out of the monadic context so that it can be passed on to the next function that expects a “plain value”.

[@kpmaynard]

Mr Beckham, you have demystified Monads completely!!! It's like you said, we do not memorize, we KNOW how to create it from first principles. Thank you so much!!!

[@alexminser1482]

This video makes a lot more sense after you read the monoids and monads chapters of Learn You a Haskell.

[@perticomanonalto]

by that you mean all the paragrafs of chapters 11 12 and 13 ??

[@dmesuoh]

You could explain monadic function composition cleaner using Kleisli arrows and the fish operator (>=>). Otherwise it's a great talk. I especially like the description of the bottom-up (imperative) and top-down (functional) paradigm towards the end.

[@ycombinator765]

I watched up until 44:53 and understood almost all of it upto the 40th minute, but I guess I need a break now. Thank you sir Brian, you are so easy and fun to listen to. I will be back in sha Allah

[@adamofathens]

This plus "The Functional Programmer's Toolkit" by Scott Wlaschin is pure KZbin gold for programmers. Cheers!

[@SamChaneyProductions]

I got here from mathematics but now I know a bit about functional programming!

[@Amridell]

I got here from imperative programming and now I know a bit of math

[@onlinesaurav]

I got here from neither and now I know a new way to irritate myself -_-

[@MorganEarlJones]

"You got functional programming in my peanut butter - I mean imperative programming!"

[@farissaadat4437]

I came from maths as well, I hope someone will answer my question on this years old comment thread but why does he refer to functions and types as forming a monoidal category instead of just saying it's a category, is he just confusing terms because categories are the 'oidification' of monoids, is he using nonstandard language, am I just missing something entirely?

[@bensculfor4630]

@@farissaadat4437 A monoidal category is a particular type of category (basically a category with tensor products): en.m.wikipedia.org/wiki/Monoidal_category

[@matthewbram4166]

Really cool talk. I really enjoy programming in Scala because it gives you the "Simplicity" of f programming but also includes the ability to create objects, all with very strong typing for compiling. When I teach my associates how to program in f, this may be the go->to video for getting them up to speed. Great talk and thanks!

[@dfurmans]

Finally I understood all content with all that small details. Such an amazing show. Many thanks for that!

[@jamma246]

This was good except I really think he should have introduced the fish operator rather than talking about bind, because I see lots of people in comments got lost around there. In a nutshell, if you want to compose functions of type a -> m a instead of a -> a one defines the "fish operator". This allows you to compose functions of the first type "a -> m a", replacing "f . g" with "f

[@ashutoshupadhye6753]

Thanks Dr Brian Beckman. Spent a day looking for sources, finally ended up here. This is what I was looking for. Thanks again.

[@johnstoner2]

This is great, but it needs an example of a 'bind.'

[@elliott8175]

Yeah - was so confused with what that is supposed to do. It looked like (fa) was supposed to "shove" its (Ma) output into (ga), which is supposed to take an (a) as an input... which makes no sense. I thought that perhaps "shove" would be an (Ma) -> (a) function, but he later contradicted that idea too, so I have no idea!

[@suneelfreimuth396]

Elliott Smith Consider composition with non-monadic functions: (b -> c) o (a -> b) = (a -> c). The bind operation allows a similar composition of monadic functions (functions which return monads): (b -> M c) >>= (a -> M b) = (a -> M c). Phrasing this as a "shove" is a bit confusing to me, as the only direct comparison that comes to mind is the Maybe monad in Haskell; think of it more as a definition for how to unwrap a monadic value for use in another function which returns a monad. If f returns a monad, then we can unwrap that monad and pass the previously wrapped value to some other function g which returns a monad. Thus, we get a function h which takes the same input as f and returns the output from g, achieving composable functions once again.

[@viktorshinkevich3169]

As I understand it adds some payload to data. For example if you had some json { data: “some data” } -> { data: “some data”, payload: “some payload” }, so the consumer of this bind has original json data as well as extra data. But it can also change stuff for example it can remove “data” and add “error” and contract is still respected as it is still json.

[@thoperSought]

@@suneelfreimuth396 that was really helpful, thank you

[@kagan770]

I lift off my hat for Brian Beckman. Amazing presentation. Far exceeding others!

[@ericlubisse8461]

+Roman Kagan It is a superb video. I should have watched it ages ago.

[@eduardo.sanchez]

It has been 9 years since this video started helping people to don't be scared of simple functions. Thanks for the great explanation and the examples with C#. It is way more clear when the syntax structure is explained with examples.

[@DryPsylocibin]

The problem with explaining monads, and a lot of other things, is that people aren't going to get it purely from the abstraction. Because humans don't tend to learn from the abstract to the concrete, but the opposite way. They see specific things, recognize patterns and then understand the underlying abstraction. But that's really hard to do in any limited amount of time; it's knowledge and awareness that builds up over time, like pieces of a puzzle starting to click in place until the picture becomes clear. Starting from the abstract (like throwing category theory at people that just want to understand monads) is like giving them all the puzzle pieces at once with no images on them, and promising that if they put it together the picture will appear. So it's actually best to use monads, for example by learning Haskell or some other language where they can be done, and get to know the identity monad, the maybe monad, the I/O monad... Just knowing them isn't enough, you need to use them to see their utility, and get an intuitive understanding for what they're composed of. Then, when digging into the theory, suddenly you're not lost but you have all these mental concepts, real things, to relate it to. With all that said, from all the blog posts I read and videos I watched on this subject, this is by far the best explanation building up monads in their abstract sense, without starting off with specific monads, that I've seen. What really makes this work is relating to concepts that will be familiar to programmers even if they don't have functional experience, but without trying to "translate" it all to imperative or OO concepts. That's an amazing feat. This video combined with hands-on experience with some specific monads is a great way to finally grasp them. What's more is that it really explains why they are useful, something that surprisingly many resources fail at. People see the I/O monad and think "I gotta jump through these hoops just to do some file writing in Haskell?", but it's as a generic concept where its power is. Thanks for the great vid!

[@andrew9800]

I come back to this talk every few years, and I learn something new each time. Really quality conversation and explanation. Thanks for posting this video!

[@michaelkohlhaas4427]

Every few years you're coming back to this video? In other words, you didn't understand anything. And I'm not astonished. This video misses the whole point of monads!

[@onoriocatenacci3387]

Ten years old and still so worthwhile to watch!

[@zanfranceschi]

this is pure gold! thank you so much for the video.

[@Sahuagin]

so you have generics. monads are just something cool you can do with generics of 1 type parameter. calling them "monads" is actually a bit confusing, because it's really more about the BIND function. there are three steps. (there are some additional technical requirements for these steps to really make you qualify, or else things won't work perfectly, but that's not important to understand the general concepts). (when I say "add a function" below, it means YOU need to DESIGN AND IMPLEMENT these functions. sometimes it will be obvious how to implement them, but you might have to be creative and make decisions about how the meaning of your type should flow when you design these.) step 1: start with a generic type of 1 type parameter. Thing. add to it a Map function. Map converts Things into Things given a function A -> B. in LINQ this is called Select. for javascript arrays it is called map. doing this makes your Thing a "functor". Map lets you convert Things to Things converting _only_ the inside part (A and B). The outer enhancement part (whatever Thing does) is unaffected. step 2: add to Thing an Apply function. Apply converts Things to Things given a Thing B>. this is a bit weird but it allows you to merge a Thing with a Thing B> and get back a Thing which has its uses. (in practice a Thing does something magical to As; this lets you combine two Things together, one that is wrapping a transformation function. you could apply, for example, an IEnumerable to an IEnumerable.) doing this makes your Thing an "applicative". step 3: add to Thing a Bind function. Bind converts Things to Things given a function A -> Thing. this allows you to convert Things to Things while not just modifying the inner part (A and B) but also modifying the outer enhancement part (whatever Thing does). in LINQ this is SelectMany. (notice that Select cannot change the structure of the IEnumerable, it can only modify the internal elements. while SelectMany totally can change the whole structure. you can turn any IEnumerable into an empty IEnumerable with a single SelectMany call; or you can double or triple the number of elements, etc.) adding Bind makes your Thing a "monad". (with some other technical requirements; like you are supposed to be able to create a Thing given an A, but that's kind of obvious.)

[@robertweissmann277]

Coming always back to Monads and more and more I get it. This one helps a lot. Thanks.

[@khanfor]

Amazing educator; you've delivered the concept successfully and smoothly. I'm going to recommend this video to anyone wants to understand Monad in Functional Programming.

[@LuxPerp]

Awesome. Thanks for posting--watching it was time well spent.

[@thirdeyeblind6369]

Shame there is not more out there from Dr Beckman. He has quite the knack for making these topics easy to understand and take in.

[@jeremywilliamson4363]

Thank you very much, I was struggling with lambda expression's in Java 8. This is helping so much.

[@ivankudinov4153]

I adore the fact that at one point the listener what so intrigued he even forgot to turn the camera to show what's happening on the board :)

[@kiraninam]

I am fascinated by this video. I am a mathematician degree holder as well as computer degree. I work in scala. I am so thrilled by this video

[@pmcgee003]

PS: neatest writing ever 🙂 21:00 Monoid 26:00 Monoidal Category 28:00 (endo)functions under composition form a Monoid 31:00 extending functions 35:00 linq is monadic in disguise 37:00 bind (shove) 40:00 type signature of bind 40:45 functions live in a Monoid, data live in a Monad 41:30 bind has to be designed - for left & right Id, and for composition 43:50 bind is the analog of composition operator in a Monad 44:25 Unit (return) is the Id in a Monad 44:50 linq as a Monad 45:50 functions + composition = Monoid. Add bind & unit = Monad. 47:30 linq works because of Monads 48:30 Monads (bind) - across different types 50:00 functions across different types 56:50 Monads (bind) - across different types 59:20 (*!*) (infix) type signature of Monadic bind 1:01:00 linq = fp = 'haskell in c#' 1:02:20 Two camps

[@zieben64]

(defn watch [starttime] ((play 15 seconds) -> (scratch/bang head 8) -> (rewind 10 seconds) -> (watch (add starttime 5 seconds)))) Not the most efficient algorithm... Seriously, this is a great video, thanks.

[@thejuan327]

six years ago i watched this video cause a proffesor comented the concept in class but didnt explained it but didnt undestand it cause didnt had some concepts, now i know the problem of manage the complexity of a system adding lines to a existing algorithm instead of use functions. Now was very simple to follow the explanation. Thanks for keep this material online

[@srinivasrg5125]

Supreme clarity. Thank you very much!

[@ericlubisse8461]

Watching this again...this is explains things really well...

[@05st43]

This was the best explanation of monads I have found on KZbin! I like how he speaks in terms of things you already know, and it really improved my understanding.

[@themodernshoe2466]

What a damn good teacher

[@oleksiyprosyanko7772]

Do you understand why we need monads?

[@DjLeonSKennedy]

One of the most cool dialog in all humanity history for all time!

[@noralworld697]

This wonderful explaination is proof that simple can be effective. I feel that I cemented a decently sized block of my understanding of functional programming. FP can be not mind bending for imperative programmers if explained properly. Thank you for posting this.

[@rishichandrawawhal6930]

Have never seen/read an easier explanation. Good job!

[@usamakhawaja8571]

Finally .... i started to understand the essence of functional programming. Hats off man ...or not ;)

[@certifiedwaif]

Thank you so much. This has helped improved my understanding enormously.

[@mmxgn]

Came to this video after a recommendation seeing if I can finally understand monads but alas I failed again. The video has the same shortcomings as lots of other "explaining monads simply" videos on the internet, that is: 1. Start with explaining intuitive and almost obvious concepts, making you think you finally got it. 2. Introducing the bind operator without actually saying what its purpose is, only much later that its somehow related to function composition. 3. Saying, "so you see, it is actually simple" without actually saying WHAT is a monad in all of this writing. Is it the bind operator? Is it a function? Repeating things such as: "See, it's not magic" lots of times doesn't make it more easy to understand. It doesn't help that at the most critical moment the person recording decided to keep the writing of Dr Beckman completely out of the picture. I actually understood much more on a video from "Studying with Alex" which shows step by step BY REGARDING NOTHING AS OBVIOUS how to implement a monad. Of course this was practical knowledge, but as a programmer interested in the monad pattern, that's what I needed. I do not give fault to Dr Beckam, the most difficult things to teach are the obvious ones.

[@philliphenry2004]

Fantastic explanations - a born communicator!

[@ShoaibKhanZ]

Watching this in 2022. In love with functional programming

[@WellSaint001]

OMG!!! thanks for this video!! This man is amazing!!! thank you so much!!!

[@123coolmik]

This guy is such a great and inspiring teacher. What a joy, it makes me want to be a teacher myself.

[@sacredinclinations]

I love Brian's manner he has clearly struggled and won against arrogance in his teaching style. Rare.

[@teeesen]

I'm not sure this is a good talk to start one off on using monads. He does a great job of making the type of bind make sense. But the problem with the talk is that it is devoid of examples. I think it would be better to show some examples of monads. How is a list a monad? How is shared mutable state dealt with using monads. Once you've seen a few examples of monads, this talk is will be good to consolidate some of your earlier learning and for seeing how monads relate to monoids.

[@Silentstrike46x]

Thank you so much for sharing this. One of my current modules in university is about functional programming, and even after listening to my own lecturer, and doing much of my own research, I just couldn't get my head around monads. After watching this video, something just clicked, and it makes more sense now. Thank you!

[@lukahadziegric5982]

Omfg. The guy behind camera -.- : Outstanding! Amazing! Wow! Excellent! Uhuh..! Excelent! Amazing! Uhuh...! Outstanding! Wow!

[@dewinmoonl]

+Luka Hadžiegrić lmao

[@Macspieler]

+Luka Hadžiegrić Seriously. Everyone here picks on Brian Beckman for wearing sunglasses and a hat. While that may not be good manner, it is by far less annoying and distracting than the comments of the guy behind the camera. I mean it's good to give the one explaining you something some sign that you are interested and follow along in what he says but constantly saying "Outstanding" is annoying for anyone watching the vid.

[@lukahadziegric5982]

Macspieler I don't care what people wear, never have. As long as they don't stink or they aren't annoying it's all fun.

[@Macspieler]

+Luka Hadžiegrić Yep exactly, especially when you are not even interacting with them in real life.

[@photoallergic]

+Luka Hadžiegrić I had lots of fun imagining his internal monologue: "(damn I have no idea what this guy is talking about. Was this cosine-thing important? F#? I have no clue why he's brabbling about music now! Dammit, just nod and look amazed) ... Aha! Interesting. Mmmmmmhm. Outstanding."

[@EcksteinNorman]

Thank you for this lesson!

[@selvinortiz]

This was brilliant and fun to watch, very nicely done sir! *hat tip*

[@tomdowad5494]

Still struggling, but now I have an idea. I don't know if it is right. Here it is: Functional composition is simple with functions of the form (a->a). Just chain them together, like a pipe. (a->a->a) But if you have two functions of the type (a->Ma), you might imagine these could not be composed into another function which had the same type ie another (a->Ma). It looks impossible because the 2nd function needs an 'a' as input, not an 'Ma'. But there is a way. And my theory is, that way is to create an inverse function of M. That is, a function that converts Ma back to 'a'. Just like the equation a = M * a * 1/M. My theory at the moment (with my extremely limited knowledge) is that the inverse function is the bind operator. That doesn't quite answer 'what is a monad', but if correct then I'm in the ballpark.

[@scitwi9164]

You don't need to invert them. You just need a "better combinator" `>>=`, which can take a value of the type `M a` (the result type of your left function) on the left, and a function of the type `a -> M a` on the right (that is, your other right-side function), and combine them into one function, which then can take the type `a` and return the type `M a`, which is the same signature as your other functions, so you can now pipeline them as before with the "simple combinator" `∘`.

[@logand-rezzer6899]

I come back to this video from time to time. The more I learn about functional programming, the better this explanation becomes. The table lookup bit was a definite epiphany.

[@jamesboulger8705]

I love this guy's enthusiasm.

[@kellybmackenzie]

Thank you so much, this was AMAZING. I love it.

[@lobzisnya]

I was lost on a bind operator. After some googling a realised that bind and flatMap is the same thing. That made a lot of sense, especially how do for comprehension(chaining flatMap's) in Scala for composing function into one expression.

[@ThomasGoossens]

"Outstanding! Absolutely! Sure!" ;-) This has to be one of the better introductions to monads I have encountered

[@numbakrunch]

Actually one of the damndest things I've ever seen. I followed along for about the first half, but I'll probably need to see it a few more times. I'm not speaking French yet. Thanks for making this.

[@bboysil]

The way he explains is almost perfect.

[@TimJSwan]

This was really great stuff. Loved it!

[@timz5418]

Thanks for awesome explanation. I'drecommend this video for all the Scala devs.

[@BasudevChaudhuri]

Awesome explanation. The best I've found so far. A follow up with examples of the 'bind' operation and actual type constructors would round this off beautifully.

[@TechLord79]

+Basudev Chaudhuri Maybe you would like to take a look at fsharpforfunandprofit.com by Scott Wlaschin, his examples like the talk "Railway-oriented Programming" are probably the best to understand the purpose and why we need it in the real world (customer-database workflow without nulls and exceptions).

[@BasudevChaudhuri]

TechLord79 Thanks. I'll take a look.

[@thepetest22]

by far the best explanation of Monads I've ever seen

[@insertoyouroemail]

He looks like a wizard!

[@mario1ua]

That's all I understood from this talk

[@insertoyouroemail]

He goes into too much detail. Monads are super simple. At first I thought they were a kind of language construction like classes, switch-case, if-statements and whatever. They're just types that follow certain rules. The same way some numbers can be called "even". We know a number is even if it follows certain rules and if we know a number is even we know we're free to do certain things with them. Same goes for a type that is a monad. So this is how it works (Using C# syntax): You need a type T that wraps another type U like T. So T would be the monad. It needs to implement a couple of methods: bind, flatmap and return. There could be one or two more methods, I don't remember. If we know something is a monad, we know we can do this for example: T x = new T(5); T y = x.flatmap(value => value * 2); It seems trivial, because it is. There is a monad in javascript called the future monad which in Typescript (because it illustrates the type signature really well) looks like this: const x= new Promise(resolve => resolve(5)) In this case "Promise" is the monad 'x' might not have its result yet but we can still do const y = x.then(value => value * 2) // "then" is flatmap in javascript So the monad "wraps" the volatility that the result might not being resolved when your code wants to deal with it. Sorry for the long comment. I was a bit frustrated when I finally learned what monads are because it doesn't need to be so bloody complicated. There are a couple of more "truths" about monads that I didn't mention but you can google "monad laws" if you feel like going into detail.

[@togimeow]

Unfortunately gaining an intuition for monads isn't so easy... have you heard about the monad tutorial fallacy? byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

[@bartdart3315]

First let me say Thank You Very Much. Super. I have done functional programming and the mystery of Monads was something i discussed with my tech lead but never pinned it down. This very good presentation has provided the inroads necessary. I think after Monoids a lot of people would naturally get lost...including myself. If Ma is explained better, and the reason for it, it would give more people the Ahaaa moment. Again, thanks alot.

[@wiegraf9009]

Did not understand until viclibcom's comment cleared up the mysterious bind: He pretty much says: "monoids are about function composition. Function composition is cool. But you can't compose 2 functions that return different stuff. Monads allow you to tell the program how to plug them together. And it is awesome, because plugging functions that return different stuff, you can do IO and other things."

[@bojanmatic024]

Not return different stuff but rather the output of first doesn't quite match the input of the second

[@demohub]

Thank you for this explanation 👏

[@davidjackowski4336]

Excellent. Outstanding.

[@smonkey001]

This is pure gold.

[@rickhernandez8301]

I'm shocked that i'm not lost. I have never done any Monads it seems simple to follow. Thank you all those late nights studying #math.

[@michaelkohlhaas4427]

I'm sure you still don't know what monads are.

[@atagen2186]

@@michaelkohlhaas4427I'm pretty sure I do, but could you explain it real quick, so I can be certain?

[@GarudaBear]

great video, thanks for sharing!

[@AvindraGoolcharan]

This guy is like the Nostradamus of programming

[@christhecode8153]

+Avindra Goolcharan Lol :)

[@juliantorp]

Just brilliant!

[@xiuxiu624]

Damn I watched this a year ago and it makes much more sense now

[@effbott]

Amazing stuff! I'm only 10 minutes in but I've already learned a lot.

[@konstantingeist3587]

So, as far as I understand, the monad syntax is basically a simplified way to composite ad hoc functions (lambdas) aka "pseudo-statements" without having to write out the whole lambda syntax because inputs are always same anyway, and we composite them because we want to pass the state (most likely a generic type) from function to function (pseudo-statement to pseudo-statement) and this way emulate statefulness. Sounds really powerful because you can completely control how statements execute.

[@dg-hughes]

1:24 another example I've heard (Prof. Sahami, Stanford) is just because you can write and understand English doesn't mean you can write a novel. I always felt I had to either be an expert at programming or not at all now I am learning all these years later and that example made sense it made me feel better. The language example is similar you need to learn in steps! Funny though I have been learning French while trying to program I find they are complimentary. I've also thought of trying piano or guitar but settled on just listening to classical music instead.

[@sysarcher]

WOW... I'm seeing this too late into my career! I've tried to explain this stuff without success. THIS IS THE VIDEO TO REFER TO!!

[@Firespirit2k]

Wow, this was incredibly useful and very clear. You sir, are a badass.

[@DavideBarasti]

Best stuff about (not only) Monads ever!!

[@EscapeTheGuitar]

Absolutely stunning ! Thanks for the clarity, and sheer sympathy you inspire ! I feel helped ! :D

[@itsacorporatething]

Instead of introducing monads using the “bind” or “shove” operator, why not use the kleisle monad composition operator (in Haskell this is >=>). Then the comparison to monoids would be airtight, without the need for lambda expressions: h = f >=> g With the type of monad composition as “(a -> m b) -> (b -> m c) -> (a -> m c)” Which is analogous to the type for function composition that you introduced.

[@nunyabusiness5977]

Great video, I wish I had seen this instead of fighting to understand monads for as long as I did. As a little critique, when he was describing function composition, he should have used f:b->c and g:a->b because it illustrates what's happening better.

[@nunyabusiness5977]

I should have watched farther. He does it around 50:00

[@Randemonium]

I love this man.

[@jakubrpawlowski]

You are great at explaining functional programming Sir! I don't know c#, f# or haskell - only JavaScript and this video helped me grasp a lot of concepts that were super confusing in Eric Elliott's Medium articles (sorry Eric - still love you too :p).

[@gracerevolution7813]

He's genius!! i feel like i can really understand what he's saying, excellent!!

[@Bratjuuc]

How can we possibly shove (M a) into a function that takes just (a) and not (M a) as argument? Don't we need to extract (a) first?

[@qandak]

Exactly! As he said "you have to design this" for a new monad. It means - how to deconstract "Ma", extract the value of type "a", and (the most significant for monads) how to handle monadic effect of "M" constructor. Take a look at some library implementations - e.g. "Maybe" monad.

[@ozjuanpa]

EXCELLENT

[@lfossati80]

When composing f:a ->b and g: b -> c, it's not a monoid, as stated in the presentation. But it is a monoidal category, so it's still a monoidal "thing".

[@falkensmaze1]

Functional languages are a step forward because of what you *cannot* do, rather than what you can. Purity means functions cannot change the state of the world, nor alter their behavior based on it. Static typing means you can't accidentally send an X where a Y is required. Immutability means you can't change data when another thread is expecting you not to. This triple threat of restrictions on what code can be has huge implications for testability, robustness, and concurrency.

[@TheBenderbej]

the best explanation ever!

[@maxi0361]

When he mention "shove", my brain turns into mud. But it does help me understand some of it. Simply put it this way, for non-functional programming, if your methods/functions always return the same thing, then they could combine together. Just like Ma = a(x,y).b(z), and we could chain them arbitrarily without exception. Really powerful.

[@jpphoton]

Excellent.