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. 😄

[@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

[@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

[@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.

[@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

[@AndreiGeorgescu-j9p]

​@@ryanleemartin7758it's because this is a bad video. Talking about monoids distracts from the point because they're only monoids in a specific way, in reality they're actually categories of the kliesli kind but that's not relevant. Could have just explained composition, explained that functors are functions that take an a and result in a variation of an a, and then showed that monads allow us to compose these functors with the kliesli operator...the end.. Instead he decides to focus for some reason on bind which isn't even relevant outside of IO monads. It's nonsense

[@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

[@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

[@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.

[@emptyjns]

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”.

[@Ashalmawia]

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.)

[@filiformis]

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

[@Dunning_Kruger_Is__On_Youtube]

You don’t get out much do you

[@herrbonk3635]

Which explains why nobody is using them for practical purposes.

[@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.

[@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!!!

[@dfurmans]

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

[@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 ??

[@adamofathens]

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

[@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!

[@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

[@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.

[@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.

[@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

[@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

[@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.

[@ashutoshupadhye6753]

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

[@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

[@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

[@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!

[@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

[@Tntpker]

So a monad is just a decorator that supports method chaining

[@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

[@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.

[@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.

[@sacredinclinations]

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

[@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.

[@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!

[@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" `∘`.

[@nileriversoftware4070]

He won't explain the bind operator, but it's the only part that's new to imperative programmers.

[@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.

[@joergbrueggmann]

Advice for beginners! Brian Beckman is right to say you go thru stages when you start to understand a new language. 1) You are scared. 2) You start learning the first words. 3) You begin to use them creatively. I wasn't scared in the beginning. But after realising that lots of tutorials failed to explain mondas in a way that I can understand - I was a bit "scared". When I was seeing this videos I had lots of questions, and still didn't understand what a monad is. And by far couldn't apply monads. Thats why my advice for beginners of functional programming with strong background in imperative programming languages is the following - similarly to Stephen Diels advice: >>> 1) Don't go thru Monad tutorials, 2) No really, don’t go thru monad tutorials. 3) Learn about the Haskell typesystem 4) Learn what a typeclass is. 5) Read the Typeclassopedia. 6) Read the monad definitions. 7) Use monads in real code. 8) Don’t come up with monad-analogy tutorials. I like Brian Beckman and share the enthusiasm with him but have to say that he brings definitions and claims proofs that are not completly correct and hence even confusing for beginners. Today, I am creatively using monads - but now I don't need this video anymore. This video was confusing in the beginning and now it is almost useless - in terms of understanding monads. However, some brain windings must have bin influenced me in a way that I still could understand.

[@DjLeonSKennedy]

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

[@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.

[@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.

[@onoriocatenacci3387]

Ten years old and still so worthwhile to watch!

[@usamakhawaja8571]

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

[@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".

[@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.

[@themodernshoe2466]

What a damn good teacher

[@oleksiyprosyanko7772]

Do you understand why we need monads?

[@ShoaibKhanZ]

Watching this in 2022. In love with functional programming

[@Silentstrike46_]

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!

[@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.

[@kennythegamer1]

So a Monoid is just a Group and a Monad is just a Group of functions from set A to set B(A) where B is some function from a set of sets to another set of sets

[@123coolmik]

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

[@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 :)

[@philliphenry2004]

Fantastic explanations - a born communicator!

[@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?

[@bboysil]

The way he explains is almost perfect.

[@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.

[@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."

[@srinivasrg5125]

Supreme clarity. Thank you very much!

[@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

[@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.

[@jeremywilliamson4363]

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

[@robertweissmann277]

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

[@donwald3436]

Are you saying that all composed functions are monoids? What?

[@AvindraGoolcharan]

This guy is like the Nostradamus of programming

[@christhecode8153]

+Avindra Goolcharan Lol :)

[@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.

[@valeriytereshchenko6198]

05:55 "You can convert any function into a table lock up" - is this true? If function have some interaction with outer world - i.e. has side effect - we really can not (at least when function made output). Every pure function may be convert to a table lock up - pure in term of FP. And some impure function also may be converted, but only some of them.

[@MicahandModesta]

I have never wanted to use the force to change a camera shot as much as around 39:00...

[@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.

[@ThorkilKowalski]

This is a fairly good lecture but it is very unfortunate that the lecturer does not provide any concrete examples of their use in a functional programming language.

[@salkdjfasldkfjsdlk]

+Thorkil Værge I feel like he's juggling fire torches while telling me how to juggle and how there's nothing to be afraid of. Then right when he gets to what a monad is he tosses the torches at me.

[@Euquila]

@@salkdjfasldkfjsdlk and previous to that he was telling us it is OK to rub gasoline over our body. "See, it's JUST gasoline... not harmful at all..."

[@jstone98]

Yup. 30 mins in is where the wheels came off the wagon for me. (Not to say he's not a superb teacher. My intellectual level is surpassed 😅)

[@PremierSullivan]

It's not you, this is a bad video

[@LTS1287]

Its a type variable. In Haskell it allows for polymorphic types or generic types in a language like C#.

[@EricDiazMD]

I still don't understand how the input gets shoved into a different type, i.e. at 59:30 Mb --> (b-->Mc). How does Mb become b? That was the part that was missing from the video.

[@RayShih]

+Eric Diaz (Eric Diaz, MD) that is part of implementation of >>=, the monad creator should define it for example, the Mb -> (b -> Mc) part for a List [b] (in this case, the array itself is the `M`) could be simply: first, extract the items inside the array (something like for-in loop), second: apply the function has type of (b -> [c]), here is the example of result [[1], [2], [3]] the final return value >>= in this case would be [1, 2, 3]

[@gofer9156]

"How does Mb become b" From how _M b_ was constructed. In the _Maybe_ monad for instance, _Maybe a_ was constructed either through _Just a_ or _Nothing_. If _Nothing_ then _(Nothing >>= f)_ becomes _Nothing_ no matter f. Generally there's *no way* for a monad to have a function g with type _(for all a), M a -> a_ (what would _(g Nothing)_ be?), which is why we have monadic bind (>>=).

[@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.

[@smash3689]

So basically wrapper?

[@timz5418]

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

[@ycombine1053]

I've never wanted to jump in to a video and ask a question so badly in my life. He definitely needs to refine good explanation of bind. Although the snippet at the end did bring some more clarity, But a less abstract example would have been helpful.

[@zanfranceschi]

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

[@jamesboulger8705]

I love this guy's enthusiasm.

[@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.

[@markskilbeck]

Me too. At ~30mins I was thinking "Wow! I'm getting it!" At ~40 mins... "What?"

[@jhorne18]

Also, f of g is very well explained in Suppes - Axiomatic Set Theory. My suspicion is that IEEE 1320.2 - Standard for Conceptual Modeling Language Syntax and Semantics .. (an excellent tutorial for first and second order concept underscoring programming), along with Suppes (or other good set theory text) would be an excellent groundwork for any objecto-riented programming. Too, it is not a bad idea to have Rasmussens work on object-oriented methods (I forgot the exact title).

[@VirtualPlasticity]

This is an absolutely brilliant video, thanks so much! One question though, I'm not clear on how Mb gets converted to b.

[@MrRedstonefreedom]

agreed, that's the only problem I'm not convinced of from a first principles perspective. The only way I could construe something reasonable is if I say "well, Mb isn't really a type, it is itself a function as well, and transitively converts" -- basically it's a type that comes packaged with its own conversion & compatibility instructions.

[@chrisdamour7456]

@58:50 he talks about ordering, but that's only because he flipped the definitions of g and f. Above f takes an a and returns a Mb, while below it's g that does this. ditto for the opposite case. very confusing

[@dhgelling]

He's simply replaced the return types b and c with M b and M c, the rest of the ordering is the same. his point is that (.) has type (b -> c) -> (a -> b) -> a -> c which makes you write, (f . g) a, whereas (>>=) has type (M a) -> (a -> M b) -> M b, so you have to write (g a >>= f). so the order of the two functions change.

[@kellybmackenzie]

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

[@spiderstheythem]

if anyone isn't sure what a "type constructor" is.. it's basically like a function that creates values of a certain types. The Maybe type (used for representing "failed" calculations; like a less angry form of exceptions c: ) has some pretty common type constructors you see a lot, which is defined like data Maybe a = Nothing | Just a here 'a' stands in for generic types, so you can have the type Maybe Int, Maybe Bool, whatever. Maybe a here is a parameter-taking type basically. Nothing doesn't take any arguments. its type signature would look like Nothing :: Maybe a Just takes a value of whatever type a is. So it has a type signature like Just :: a -> Maybe a So you could say Just 3 if you were working with Maybe Int, or Just "haskell" if you were working with Maybe String. In this video, when he's working in the "world of types" as he puts it, M a is like "Maybe a". You could have M Int, M Bool, etc. It's a type, or a type of types if you will. when he's talking about a type constructor, a specific value returned, M a is like Just. it's a function call on a value a that gets you a result of type M a.

[@pohjoisenvanhus]

So I get to compose and pass an environment/context with side-effects around inside containers with a constructor that wraps and a method which allows applying other functions to the value and getting in return an another container with a similar interface as long as the types line up like A, MA, B, MB, etc. Uuh.

[@darylewalker6862]

For the last part, where the Brian explained the ">>=" operator as "Mb -> (b -> Mc) -> Mc", how do you go from the Mb in the first term to the "b" as the input in the second term? Is there some sort of counter-M applied first? Is the "M" from the first term recombined with the Mc returned from the second term to create the third-term Mc?

[@NathanHedglin]

Unwrapping. Mb is the same as List in C#. We just take the value out. In JavaScript, { Info: "blah", value: 10 } the object is M and the value is our b. If we want to add 10 to that value we first need to get the value, 10, out of the object first.

[@somebodyelse9130]

That depends in the type. For example, [b] (a list of things of type b) is a monad. Then the question is "if I have a list of 'b', and a function that takes a 'b' and returns a list of 'c', how do I get a list of 'c'?" Another monad: the Maybe monad, where "Maybe a" is either "Nothing" or "Just a". Then the question is "if I have a 'Maybe b', and a function that takes a 'b' and gives back a 'Maybe c', how do I get a 'Maybe c'?" The answer is different for them both. For Maybe, it's that if the 'Maybe b' is 'Nothing', the 'Maybe c' is also nothing. If it's 'Just b', then the function operates on the 'b' and returns the 'Maybe c' like it says.

[@NikitaGrygoryev]

I know nothing about programming and very little about category theory but is the construction from 38:41 something like a Yoneda functor?

[@ericlubisse8461]

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

[@pohjoisenvanhus]

So to sum up after listening this through for who knows how many times: one should make functions that are monoids, or at least monoidal, in order to make things composable and to give them math like properties to make programs easier to reason about as suggested also by Backus in his Turing award lecture. But monads? I'm still trying to figure out what they'd actually be practically useful for unless you're looking for a workaround to have side-effects in a purely functional language.

[@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.

[@EGDmitry]

The symmetry aspect looks kind of artificial to me. The lambda on the left side is really a lambda for the whole expression (as shown on the video as well), so yeah, visually it looks like a composition of things of the same time, but in reality you can't quite compose them like that (for example you can't just store lambdas in the list and do msum or foldMap with mappend = (>>=), types just will not match) Isn't it fine for bind to be asymmetric: m >>= f = join $ fmap f m?

[@PeteRyland]

Totally agreed. I watched this video some years ago and it actually set me back in my understanding of monads at the time. Now that I'm quite comfortable with them, it's actually now quite academically interesting the way this is presented as almost symmetrical, but I would never teach monads like this.

[@mAcCoLo666]

Well if you look at the bind operator as working on functions, it is actuslly composing things and it's symmetrical. It's just that you need to start somewhere, I guess. Take Maybe for instance. You could theoretically just define all of your functions first (a to maybe b, b to maybe c) and then compose them via bind (a to maybe b bind b to maybe c), but for practical purposes it's arguably easier to let it operate on the type itself (maybe a to b and maybe b to c). But it would still work the former way.

[@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.

[@herrbonk3635]

Static typing is standard in ordinary procedural languages, say algol, pascal, modula or ada. There are pure functions as well (as opposed to general procedures), when you need them.

[@rishichandrawawhal6930]

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

[@cbbuntz]

I love how much he dumbed it down. I've always been confused by certain mathematical notations, but I had no problem with this. For example, nobody ever explains what the lambda symbol means. I watched so many videos about lambdas and they all talk anonymous functions and closures but nobody ever explains what the notation means.

[@101graffhead]

>hey dude monads are easy >video length 1.07:10

[@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!!

[@gracerevolution7813]

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

[@FrontendTopics]

43:21 I got lost exactly in the part where he says people get lost. How is he doing the composition if f: a -> Ma and g: a -> Ma, how the bind is working ?

[@rckd5903]

The bind (aka map aka chain) operator simply composes two functions and puts them in a new monad. If you bind the function *f* to a *Monad of g()* you get a *Monad of f(g())*

[@LeCoolCroco]

@@rckd5903 so the Monad is a wrapper on the returned value which is decomossed into the value of type a in this case?

[@rckd5903]

Vladimir Stajilov Kinda. Monads in general are just "wrappers" around something (they can contain values, functions, other monads, ..) with some "laws".