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."
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
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
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.
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!
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.
@@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
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”.
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!!!
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
(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.
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!
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.
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
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.
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
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?
@@farissaadat4437 A monoidal category is a particular type of category (basically a category with tensor products): en.m.wikipedia.org/wiki/Monoidal_category
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!
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!
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.
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.
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.)
This was the best explanation of monads I have found on TH-cam! I like how he speaks in terms of things you already know, and it really improved my understanding.
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.
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
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
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.
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!
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!
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.
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.
+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).
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.
+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.
+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."
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.
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
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.
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!
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.
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" `∘`.
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.
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.
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."
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.
+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.
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.
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
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.
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".
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.
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.
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.
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.
+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]
"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 (>>=).
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.
Cheers to Brian Beckman for the explanation, but (sorry to say) the way the camera handles the view is very distractive. It focuses on the wrong things or actually it does not need to move at all. Just sharing my thought for the next one.
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.
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.
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.
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.
I think the biggest issue with this idea of programming in F#, Scala, or another hybrid language (as he suggests), is that it allows you to violate these Monadic laws arbitrability, haskell's compiler will pick up any attempt to violate any monadic law, maybe I'm wrong about F#, but the biggest criticism of scala (from users from r/haskell at least) was this simple idea, you may have monads, but you have none of the benefits without personal discipline.
there is no compiler in the whole world that can formally prove that the monad laws hold for an arbitrary type. it's an undecidable problem. in actual programming, the monad laws are rules that you are highly encouraged to make your monads adhere to so it's less confusing to clients of your code, but you can never ever enforce them statically.
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.
![⭐ฮิตในTikTok!! ( หมูเด้ง MooDeng ) Ver. แดนซ์โจ๊ะๆ ReMix BY [ ดีเจกิต รีมิกซ์ ]](http://i.ytimg.com/vi/3krsyfWUeHU/mqdefault.jpg)
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."
+Collagenre Totally the best part of this talk!
reminds me of bob ross
uuu
I'm fortunate enough to get to work with Brian, he's just as great in person.
Hahah, comment of the year. 😄
i want to listen to this gentle wizard man explain everything to me for hours on end
he has a very nice & comforting voice
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
For anyone confused he's refering to Erik Meijer and LINQ
Excellent talk from the bad guy from Half Life 2
+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"...
Lol. He knows all secrets with lambdas)
and the symbol in Half Life is a lambda ... were they trying to warn us of the dangers of functional programming?
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
SongMachina lambda is also the symbol for half life in physics
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.
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!
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.
You're coming back to this video because it's a total mess!
@@michaelkohlhaas4427 lol, fair enough
Truth
@@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
36:00 "Let me stop recording the whiteboard at a critical point, and rather focus on the speaker's ear."
It's because he's focused on the instructor's gonads and not his monads.
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”.
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!!!
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
(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.
This video makes a lot more sense after you read the monoids and monads chapters of Learn You a Haskell.
by that you mean all the paragrafs of chapters 11 12 and 13 ??
The only man on the planet that both understands what a monad is and can explain it.
You don’t get out much do you
Which explains why nobody is using them for practical purposes.
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!
This plus "The Functional Programmer's Toolkit" by Scott Wlaschin is pure TH-cam gold for programmers. Cheers!
I lift off my hat for Brian Beckman. Amazing presentation. Far exceeding others!
+Roman Kagan It is a superb video. I should have watched it ages ago.
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.
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
This video makes monads pretty easy to understand.
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.
VICTUALS
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
Thanks Dr Brian Beckman. Spent a day looking for sources, finally ended up here. This is what I was looking for. Thanks again.
I got here from mathematics but now I know a bit about functional programming!
I got here from imperative programming and now I know a bit of math
I got here from neither and now I know a new way to irritate myself -_-
"You got functional programming in my peanut butter - I mean imperative programming!"
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?
@@farissaadat4437 A monoidal category is a particular type of category (basically a category with tensor products): en.m.wikipedia.org/wiki/Monoidal_category
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
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!
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.
Finally I understood all content with all that small details.
Such an amazing show. Many thanks for that!
This is great, but it needs an example of a 'bind.'
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!
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.
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.
@@suneelfreimuth396
that was really helpful, thank you
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.)
This was the best explanation of monads I have found on TH-cam! I like how he speaks in terms of things you already know, and it really improved my understanding.
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.
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
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
Finally .... i started to understand the essence of functional programming.
Hats off man ...or not ;)
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.
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!
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!
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.
Ten years old and still so worthwhile to watch!
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.
+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).
TechLord79
Thanks. I'll take a look.
One of the most cool dialog in all humanity history for all time!
He won't explain the bind operator, but it's the only part that's new to imperative programmers.
So a monad is just a decorator that supports method chaining
This guy is such a great and inspiring teacher. What a joy, it makes me want to be a teacher myself.
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.
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.
I'm sure you still don't know what monads are.
@@michaelkohlhaas4427I'm pretty sure I do, but could you explain it real quick, so I can be certain?
Omfg. The guy behind camera -.- :
Outstanding!
Amazing!
Wow!
Excellent!
Uhuh..!
Excelent!
Amazing!
Uhuh...!
Outstanding!
Wow!
+Luka Hadžiegrić lmao
+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.
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.
+Luka Hadžiegrić Yep exactly, especially when you are not even interacting with them in real life.
+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."
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.
Watching this in 2022. In love with functional programming
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
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.
I love Brian's manner he has clearly struggled and won against arrogance in his teaching style. Rare.
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!
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 :)
Coming always back to Monads and more and more I get it. This one helps a lot. Thanks.
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 😅)
It's not you, this is a bad video
Fantastic explanations - a born communicator!
The way he explains is almost perfect.
Supreme clarity. Thank you very much!
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.
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" `∘`.
This guy is like the Nostradamus of programming
+Avindra Goolcharan Lol :)
What a damn good teacher
Do you understand why we need monads?
Thank you very much, I was struggling with lambda expression's in Java 8. This is helping so much.
this is pure gold! thank you so much for the video.
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.
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.
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."
Not return different stuff but rather the output of first doesn't quite match the input of the second
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.
+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.
@@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..."
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.
Me too. At ~30mins I was thinking "Wow! I'm getting it!" At ~40 mins... "What?"
I love this guy's enthusiasm.
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
Thank you so much, this was AMAZING. I love it.
Watching this again...this is explains things really well...
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.
Thanks for awesome explanation. I'drecommend this video for all the Scala devs.
Have never seen/read an easier explanation. Good job!
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".
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.
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!!
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.
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.
He's genius!! i feel like i can really understand what he's saying, excellent!!
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.
+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]
"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 (>>=).
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.
Are you saying that all composed functions are monoids? What?
Cheers to Brian Beckman for the explanation, but (sorry to say) the way the camera handles the view is very distractive. It focuses on the wrong things or actually it does not need to move at all. Just sharing my thought for the next one.
Awesome. Thanks for posting--watching it was time well spent.
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.
I know nothing about programming and very little about category theory but is the construction from 38:41 something like a Yoneda functor?
how does this not have more views
This was brilliant and fun to watch, very nicely done sir! *hat tip*
I have never wanted to use the force to change a camera shot as much as around 39:00...
That was the description of the experience of learning french from a man who never did.
Damn I watched this a year ago and it makes much more sense now
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.
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.
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?
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.
by far the best explanation of Monads I've ever seen
I think the biggest issue with this idea of programming in F#, Scala, or another hybrid language (as he suggests), is that it allows you to violate these Monadic laws arbitrability, haskell's compiler will pick up any attempt to violate any monadic law, maybe I'm wrong about F#, but the biggest criticism of scala (from users from r/haskell at least) was this simple idea, you may have monads, but you have none of the benefits without personal discipline.
there is no compiler in the whole world that can formally prove that the monad laws hold for an arbitrary type. it's an undecidable problem. in actual programming, the monad laws are rules that you are highly encouraged to make your monads adhere to so it's less confusing to clients of your code, but you can never ever enforce them statically.
"Outstanding! Absolutely! Sure!" ;-)
This has to be one of the better introductions to monads I have encountered
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.
Its a type variable. In Haskell it allows for polymorphic types or generic types in a language like C#.
Best stuff about (not only) Monads ever!!
Loved the explanation. This man is a very good educator.