My experience as well, though I realise as much having already understood the concept via classic methods (see a book on Haskell), so I was like "Yep, that's totally it". I doubt it would have helped me if I had used it as tutorial material. Still, a stellar explanation
you have to trick a veteran functional programmer into helping you if you start explaining monads to enough people that already understand them, eventually one will tell you 'oh you don't _actually really_ understand monads unless you understand…' and suddenly you will feel this clearness in your brain you can suddenly explain this concept and all of the useful ramifications
After maybe 10 years of periodically going back to the definition of monads, googling and still not understanding what the hell they are, you have done it! Thank you, one less mystery in life.
I mean, "Its just a monoid in the category of endofunctors. What's the problem?" Scott Wlaschin also does a great job of explaining monads graphically with his "Railway Oriented Programming" talks. But this was a great "part to whole" way to take a single use case and expand the concepts, step by step. Nicely done!
at 4:24 you have a bug. `wrapInLogs` is undefined. I think you meant to assign `a` to `wrapWithLogs`. Other than that... this is the best explanation of the monad pattern in JavaScript ever created on RUclips!
I founded Vancouver's Functional Meetup which ran for 3 years...and we discussed monads a lot!! I had a lot of ongoing questions. I saw many presentations, yet I was always left wondering / wishing someone could actually show me a 'monad' rather than discussing the apparent philosophy or upper purpose! Finally, someone explained it with great code examples, which I could easily relate to Swift (my language) and completely and finally understand monads...I had assumed one didn't really need to know 'monads' to use them, and it turns out with arrays, maps/flatmaps, optionals, and even a plug in Then promise library - all these were monads of course and I didn't need to know one to use one...but your explanation nails it! Many thanks!!
Very good explanation, finally someone who's using a programming language which people who don't yet know what monads are can actually understand. Another good video on the subject is Brian Beckman's "Don't fear the Monad" which explains it in a more abstract way, but still using familiar terms. Other videos, and especially Computerphile's video were completely inaccessible to me and left me thinking that I'd need to spend months studying category theory or at least read a book on Haskell before I could understand this concept. You and Brian made me realize that I had actually invented monads on my own and have been using them without knowing what they are.
It's funny you mentioned the computerphile video because I likewise, even in using monads wherever applicable, watched that video and felt like I understood it even less. Even funnier still is the disclaimer he gave of "well people criticize mathematicians for not being able to explain their concepts in relatable terms, but I think they should just get over it". And it's like... they will get over it, by just ignoring their work & having to rediscover it anyways in their own contexts.
As someone who didn't know monads, this is an excellent video! You started with an iterative approach on simple examples to give an intuition of why the idea of monads is useful. Then after having the intuition you give a more abstract, rigorous definition, along with real usages. I think I wouldnt have been able to understand the abstraction as easily if there wasnt the simple examples in the beginning. Then you give a summary to help remember the content of this video. Overall I think the flow is great and the pace is just right. Sometimes I have to pause a bit to understand the code but I never have to think really hard to understand since the leaps in logic are always small enough. Thank you for making this video!
That was fun to watch. I've been writing rust for a good while now, so basically I've been using monads everyday all this time without knowing the concept's technical name. Watching you refactor bad typescript step by step into rust felt funny.
One helpful trick that can help people adopt/be aware of a defined technique or pattern is to avoid giving it a name that sounds like a portmanteau of “moron” and “gonads”
@@ChrisD__ u cant understand rust, because rust is a political marxist cult of mentally ill activists good luck in ur cult journey : ))) rust is literally trojan horse in linux kernel
Very interesting and new to me. One small thing; what you call a caret, < or >, is more properly known as an angle bracket when it is used as a delimiter. This is a caret: ^.
Dude, I literally was using Optional without knowing what is it and how it actually supposed to be used. Huge thanks for explanation, found your channel today and already fallen in love with this and passwords videos!
Just for reference, in C# flatMap for lists (actually, all collections that provide IEnumerble interface) is SelectMany in Linq. Future/Promise is the Task. One more interesting thing - async/await (combined with Task) is very close by it’s behavior and purpose to IO monad (not mentioned here) - it “infects” function so you need to make functions that call it async (or, at least, return Task) as well. And it brings a big mindset shift, starts building understanding that we want to keep “IO monad” part as small as possible, splitting logic and IO. It will allow to write most of tests without mocks at all. And the rest that works with “outer world” (db, user input, other services calls etc) better to test with real interaction, e.g. integration tests.
The second part you wrote is potentially a good point, but I'm not convinced it's true. I know exactly what you mean by "infection" (I call it "prionic", and if someone doesn't know what a prion is, I go for ice-9 if they've ever read Vonnegut). But, I'm not sure it's really possible to have async in any kind of way where it doesn't "infect" all of its uppers. Actually, callbacks in JS would possibly do this. But that's more a matter of using global state. Although, additionally, mutex's in general work this way. Thinking of reentrance patterns and such. Ok, you've convinced me. Yea I think this is a unique quality for Task. Even deeper, I think this may be a unique quality for Monads, overall. An accessory requirement for that to be the case is BTW this is somewhat similar to the mathematical concept of "absorbing elements". I think Undefined, though, would most-closely mimic the concept of a synthetic (ie intentional union with) construction of a category with an absorbing element.
**An accessory requirement for that to be the case MIGHT be that it's a typed language. Though I think that's just a straight matter of "in order to be less immediately annoyed of categorically wrong implementations"
@@MrRedstonefreedom Typescript (in the video) gets compiled into normal Javascript, mostly by stripping away the types. So the async/Promise stuff usually becomes the exact same operations in Javascript. For that matter, the node.js runtime has a utility function util.promisify() that converts a callback-using function into a Promise-using functions, and Promises have .then, .catch, .finally etc that resolve Promises with callbacks. The two are essentially equivalent.
Best video i have seen on this topic. Most videos start with explaining monads, monoids, and endofunctors and are completely overcomplicated. Starting with an easy to grasp example is way better
Jesus, this is such a robust explanation. This could be watched every 3 months just to reconsider newly-encountered applicability. I already came to the same conclusions about monads in programming (as a design pattern, in any kind of paradigm or language), and done a lot of deep thinking, but even still, this is such a wildly useful video as a consolidation tool. You've given a lot of excellent visualizations that make aspects-management & its expression a lot easier.
I've always thought that the definitions people used are always more complex than they need to be. I'm glad you've managed to explain it in a way that feels like something a programmer would do
@@AndreiGeorgescu-j9p i don't, and i'm a little confused at what you're implying. do you mean that no "real" programmer requires it to be explained like this? or that you don't think the code in the video is very good? please, enlighten me
@@erikgrundy a software engineer is supposed to be an engineer. An engineer uses math and science to solve real life problems. However "software engineers" are the only kind of engineers who hate math and science and think even simple basic math is "too complex" and are always looking for immediate answers on "how" to use something, with very little understanding of "what" something is or "why" it is. The explanation above is terrible for very many reasons but mainly because he doesn't actually explain anything any what a monad actually is, it's just overly convoluted examples of what you can do with it which ironically is more complex than if somebody just explained what it is. You saying "feels like something a programmer would do" means code monkey because actual software engineers understand math and don't explain things this way
@@AndreiGeorgescu-j9ppretty elitist take in my opinion. I think the video does a great job at highlighting the use and benefits of monads from a practical perspective. Many people, engineers and otherwise, benefit from illustrative examples as points to jump off of and then abstract. You are free to complain about what you think engineers should and shouldn't do until the cows come home, I'm sure that's much more useful. Or, if you're so concerned about software pedagogy, why not put your money where your mouth is and make a guide yourself? But I understand, hiding behind cheap talk is much easier. These lazy software engineers, right?
@@AndreiGeorgescu-j9p in the same breath, “engineers solve real life problems” and “they only care about *how* to use tools” Using tools is what solves problems. It makes sense that engineers prioritise practical use over formal understanding. Save the high-level math for academia and research.
One thing I’ve noticed that is tricky is when you have a value wrapped in several monads. For example, if you have a value that is asynchronous and also can fail with an error. Then you have a value wrapped in a Future/Promise/Task as well as an Either. Would love a video about how to deal with this complexity. How to traverse between different monad lands.
Yep, because Promise.then() has the same type signature and meaning as flatMap (or bind in monad). It transforms promise, using a function transforming wrapped value into a new promise.
@@ivanjermakov wouldn't this be trivially solved by back-tracking the function through the unwrap, since both monads are Generic in their implementation? If you have a Future, what you probably have is something in the form of future(optional(5)), which can also be expressed as a chain operation as: let result: Promise = createOptional(5) | .createFuture($0) in which case you should probably be able to do something like `result.value.value` which should resolve without much problem: Unfulfilled promise would nil .none in the optional would also nil
Very nice overview. One thing that could be helpful: flip the "normal" and "monad" land in your state graph (9:45) and then explain that "wrap" is sometimes called "lift".
Oh, so this is what they mean when they say that monads can be used to avoid side effects but can replicate the effect when you need to. Say for example, Instead of having a global array that is referenced and mutated by every function to concatenate logs into it, you can return a concatenated array as part of a monadic value, one that is created at the beginning of the chain and is returned as a value at every step of the way 'till the end. I mean, in this case we are using an array object, so it's probably still being referenced as a pointer, but still, the concept stands as it belongs to the chain of operations alone.
Thank you. this video is very practical, informative, and truly demonstrates what can be achieved with monad with actual example and not just the abstract concepts of it all. Best one yet that I've seen on RUclips. You've earned a new. subscriber!
I watched a bunch of talks about what monads were, but this was the first to make me realize that I actually wrote one unintentionally last year while trying to learn about design patterns
I loved this video. Would love to see some explanations on applicatives and functors as well and some fp-ts examples. The pipe and flow makes using monads and functors so nice
Never heard of this, but I can see how to make it in different programming languages now. So it's just any helpful pattern to make code seem simpler while hiding busy works... Knowing this I could make simple program documentations by mentioning for what I would need monad for in the functions... Monad for value that logs itself, gives more programming simplicity, changes value using server connection, changes other program settings to make this one appliable... I guess I could just add reusable lamda functions for functions which process those values, when they are attached to the function, so I need a function to attach them... Now monads would be moddable by programmer aswell at the start of loading the program! So now I got Function class and can create more usable functions for my needs at the start up with less code which behaviour I can change by attaching more functions in it. I can add value to it, it get's processed by all lambda functions I've attached to it, but only one changes it and other uses it to do other stuff. I create function at start up as static and give it a name and attach functions. Now I could just call MyCustomStaticFunction(value) and all lamdas get called internally, perhaps knowing the old value and the new value.. I'd like to use preprocessor function so it would apply code in the binary release in that location instead of going back in memory to that function location, but it's ok for now... Build is smaller, but code also runs slightly slower...
13:30 It's called flatMap not only for lists, but for any type that introduces structure. More generally, it's called bind or concatMap, it has a type signature of (struct: Struct, transform: (value: T) => Struct) => Struct, and means "Map a function over structure and concatenate the resulting structures". It is possible, because any monad must also be a monoid: define how to combine structures. Basically, monad is a very general interface for flatMap.
I just made a monad this week without even realizing it, but I never thought about implement logging into it. I'll need to do that immediately because that would be extremely useful!
Dude. This was fucking sick, please keep producing videos like this. I think there's also a lack of beautiful visualisations for more advanced concepts (which makes sense because more people are going to be beginners). Keep it up man, your animations are absolutely gorgeous :)
The fact that Swift has built in operator support for optionals using ? is so nice. It’s nice to be able to wrap up this behavior into a simple type declaration like User? (equivalent to Optional).
Just to be nitpicky, the wrapper of the type is not a part of the monad. The (in)famous sentence is true: A monad on A is a monoid of the endofunctors of A. This means that the it is a F: A -> A, meaning that both the original object and the end object must belong to the same category. In your examples, you are doing two different operations: - An isomorphism, F: U -> W, where U are all the unwrapped objects and W are the corresponding unwrapped objects. - A monad, G: W -> W, where the monad acts on any wrapped object and returns the same type of wrapped object. Not that it is fundamental to program or anything, as most of the time combining both is the easiest solution (multiple times my functions accept different types for certain arguments and I internally transform those arguments into the type that I actually use in the function, like passing the name of a matplotlib cmap, and then I get the cmap, but also allowing to pass a cmap itself). Another nitpick to make is that in pure functional programming, the "busy logic behind the scenes" cannot affect anything else other than the object being returned. For example, if instead of adding the log to the object you wrote it somewhere else, that also wouldn't be a monad, even if that function would work exactly in the same way, being able to chain it as much as you want.
Because side effects have side consequences (for real), that goes outside of pure functions. It’s some shady area tho, because adding to a list may have the side effect to increase its memory footprint, pure "pure" functions (on technical side) is barely relevant to most programmers.
@@gweltazlemartret6760 There's an interesting research language called Koka that uses an algebraic effect system instead of monads. I believe 70% of its stdlib has the "total" effect, meaning those functions: * Are guaranteed to terminate * Are guaranteed to not throw an exception * Do not touch the heap * Do not mutate any state * Do not do IO etc. The total effect is even more restrictive than what a "pure" function in Haskell is. So the fact that a large portion of the standard library can be made of functions with the total effect shows that total pureness is somewhat relevant to programmers.
Dang. Within only 15 minutes you easily achieved what my professor in functional programming couldn't in an entire semester of 15 weeks lol. No seriously, this video has to be the best explanation for Monads one can find on RUclips!
i watch a lot of videos on monads and they always focus on the generic aspect of the monad wrapper, but really this video nails behavior aspects which is what really matters. you can even write monadic code in C using this examples and still have great value using it.
"A monad is just a monoid in the category of endofunctors, what's the problem?" for anyone wondering, was satire from the beginning (though the first part was taken from a math book, where the sentence does make sense in context).
Every time I've heard an explanation of Monads I've been completely confused. As soon as I got to the part that mentioned Options, my Rust brain exploded and understood everything. Best video on the topic by far.
I kept seeing this video recommended to me, but I avoided it everytime thinking "this is gonna be too complicated, I'll watch it later when I have the time/energy." Glad I finally bit the bullet and watched it... was not disappointed. Fantastic explanation... please keep making videos like this!
This remembers me of my favorite feature of dart, Option (var?). It is beautiful how you can do more if you value can be null or have a value instead of always having to have a value. Using (?) and (!) in dart makes the code much easier to read.
Impressive explanation. Quickly provided useful information that gives me better understanding of techniques I already use as well as new ones to adopt.
This is a great vid, but I'm not 100% sure about the example at 9:00. A lot of people will either: - Include the conditional undefined return from the run function inside the JS methods - Want to handle each undefined case slightly differently In the former case, your code would be as clean as #2 without requiring the run wrapper. In the latter you'd end up with #1 where the run wrapper would just add clutter.
I recently discovered Effect-ts and was struggling to understand the basic concepts of it. The docs don't mention mondas while explaining how the library works (due to a valid reason. Mentioning monads scares people!) But this video explains it beautifully! Thank you man! You got yourself a subscriber 😊
Thank you for this extensive explanation! 👍It's really useful as a background knowledge behind a ton of things in Rust that I learned, also because I have seen many people already talking about it there. Now I really understand it. 👏 But even in C#, a language in which I have worked for about 20 years now, I can relate several examples of monads as well. A nice one are so called LINQ functions, for example SelectMany, which is basically the literal equivalent of your FlatMap example. LINQ is the name of the most important functional programming API in C# and DotNet. Maybe it is also a good to mention that C# was really one of the first with the async await programming model, and it might even be the absolute first one. Though what you mentioned as Future or Promise are not the terms how they are used in C#, but what is used is generally Task or ValueTask, although other types can also be used sometimes.
Amazing work here. Turns out I've been partially harnessing the power of monads the whole time, but understanding how you can simply chain passed functions brings my software engineering understanding to a new level. Thanks for your effort in making this video Alex.
I don’t do a ton of programming with my job but I’ve just started a project that requires me to write a code that needs to handle a bunch of undefined data and I was wondering the best way to do that was, lucky I stumbled across this video in a perfect coincidence
Hey Alex, thanks for this video. I'm sending it to all my software engineer friends who have heard of Monads but have no interest in figuring out if its actually a good idea.
This is a nice abstraction, but we should be careful of making sure the performance hit is less than the benefit, and also be careful of unintended, "backstage" byproducts. We should use this pattern only when the advantage of using it would be tremendous, and not only for code to look a little nicer.
Can you give an example where it has any advantages at all? Other than being used to show off the giant size of somebody's intellectual balls, that is. ;-)
I think a large part of the issue explaining Monads is the concept is actually so simple that there is a "why the special name?" question that makes people think it _must_ be more complex. It is a basic function-application pattern, the likes of which you learn the first time you write an async event loop, or implement a DSL-FSM (See Greenspun's 10th rule). And yes, just like the y-combinator, or lambda calculus, it has a basis and explaination in math that makes it look more complex than it really is.
In Javascript Promises/Futures are an example of a Monad, and in that case then is flatMap/ >>=. However, Monads generalize the idea of promises/futures to be able to embed any language with any sort-of semantics into the language, so promises/futures are a way of embedding asynchronous computing into a stateful language and have it look like synchronous code just like monads are used to embed imperative/stateful languages into purely function Haskell. The thing about monads is that you have to know their 5 other definitions and many other examples to see how monads can shorten your code by. You have to know Monads other definition like flatMappables containers where flattenable containers are called Monoids, Mappables are called Functors.
If you wanted to implement logging quickly and cheaply, what you'd actually do is have a logger variable that gets passed by reference into anything that is going to log something, and the function does the log. One string construct-write, all writes going to the same place. The logger can even be something as simple as a string array. 8:02 This is a bit more understandable if your language can't pass multiple return values. I still think a templated stuct that has a bool and the raw type would be better, because you can just construct that as a return value and check the bool to see if the result is valid. If you had a modern language that supported multiple returns, you could just return a bool and the raw type, and have a metaprogram check that the success parameter is checked if you need to. 8:22 Undefined is bad, always. Behavior and return values should always be defined in every case. Undefined behaviour is a bug. 8:50 In this example, if you use multiple return values, you can make the "Without Option" code much neater. 9:26 In my opinion, complex things should not be handled behind the scenes. That's how you get slow, inefficient, buggy code especially if you prematurely optimize. To be fair, this is kind of an borderline case. Neatness and abstraction are valueable through apparent simplicity. The design decision every programmer has to make is "how much of a win am I getting here?" and consider alternative methods to achieve a similar result. 10:37 This makes it quite clear how much busywork the computer is doing in the background when the thing you're actually trying to do shouldn't require it. The only win you *might* get, in terms of speed, is if, in the case of Option, something might become nothing at any step of the process. Otherwise you're wasting cycles wrapping and unwrapping things. This is busywork you're making the processor do that it didn't have to. This is SLOW. 11:58 I know enough about multithreading to know this isn't how you want to do it. 13:53 This is also slow, unless you're doing this in a functional language that can do all kinds of calculas on your program to make it go fast. I'd argue that functional laguages have many other downsides that make you not want to use them, but this isn't the place for that. 14:05 Let me rewrite this for you. Monads are a slow design pattern because they let you chain operations with apparent simplicity while hiding work that the processor actually has to do behind the scenes. Final conclusion: This is actually a very well put together and informative video, explaining a very abstract concept in very tractable terms. I would love to see more videos from you on more sensible design patterns. Despite all the hate for monads in this comment, you've done a very good job here Alex.
If i'm seeing this right, it looks like a technique to bind operations that don't want to know about the all parts of a data structure to only the parts it wants to know about, in a way that's easy to extend both on the supported functions, and the underlying data structure. And then the broader secret work clicked
Bro, you're a legend. I've tried at least a dozen times before this to learn about monads. Wikipedia, googling, videos... was always left with the feeling that even though I didn't get it, the explanations were all trash. This video is so clear, I immediately understood the concept and how it was useful. And some old examples of monads that still rattled around in the skull suddenly made a lot more sense. Thank you.
I've been doing this for years and just calling it good encapsulation and treating functions as a blackbox. Reduce how much the caller needs to know about the function and allow it to be a blackbox. Or rather I suppose, how to create the blackbox in the first place. Good to know the new vocab for it and this is a really good explanation, much better than I could give to new devs. I'd frankly send them to this video to learn the concept.
Despite having already been exposed to monads through Rust's Option and Result types, your NumberWithLogs example gave me a better understanding of just what all I could use this pattern for. Thank you.
@@itellyouforfree7238 as per the description in the Wikipedia en.m.wikipedia.org/wiki/Monad_(functional_programming) page for Monad, the NumbersWithLogs type is missing one of the defining elements that would make it a monad. There is no function as part of the type that allows different instances Of NumbersWithLogs to be composed. This is the bind or flatMap function which he references in the video but does not implement. You can see this where he stores the results of runWithLogs in variables. If he renamed runWithLogs to flatMap and made it a method on the NumberWithLogs type and removed the first parameter, then it would be closer to a monad. It might then look like this. wrapInLogs(5).flatMap(addOne).flatMap(square).flatMap(multiplyByThree). This would return an instance of NumberWithLogs which you would need to extract the result from. In fact if NumbersWithLogs was made generic say SomethingWithLogs, so the number parameters would all become T, then you have a Writer Monad.
@@jfredericks309 At 3:40 he writes the function `runWithLogs`, which is the "bind" function that makes `NumberWithLogs` a monad. There is no need to make it a "method", it makes no semantic difference. He intentionally avoided making `NumberWithLogs` generic to simplify the example. if anything, what is missing is that he never mentioned monadic laws. Those are what makes something a monad, not the name of the functions or whether it's a function or a method.
Having watched my fair share of videos, read articles and even delved into some theory behind lambda calculus and functional programming and still not understanding fully what monads are or how to even use them, I was reluctant to watch your video. "There's no way someone can explain monads to me in 15 minutes." I was gladly mistaken. You did the impossible and made monads click for me all the sudden, at least, in a practical way... so thank you very much
7:18 There is a type error in this code. The type of `transform` should be `(_: T) => Option`, and then the return type of run should be `Option` indicating that transform is allowed to change the underlying type. This is necessary for functions like `getPet` and `getNickname` in your next example.
Great video! One small correction, though: For the Option run method, you list that it only has one generic parameter. This implies the input type of the transform function must be the same generic type of the transformation's returned property. That's not true, since the getPet transformation transforms a User to an Option.
I code mainly in Rust and PHP. They are both mixed paradigm languages, but I must say that using the Option type to guard against null values and the Result type to instead of Throwable+try-catch makes for much, much nicer code.
Never new the concept of Monads before watching this video but realized that I have been using this pattern without knowing its formal name. In java Optionals and Streams kind of serve the role of Monads only without the boilerplate. In spring reactor flux/mono also serves the role of monad. I am sure there must be more examples. I suppose that other languages also have features/libraries that abstract away the boilerplate of Monads. Sure, there might be cases when you would want to implement such a design pattern from scratch. Still nice to see low-level implementation spelled out in JS.
At last! Great video thank you so much!Great namings, wrapper instead of unit and run instead of flatmap or bind to explain the concept before the terminology. Please make more videos like this
I've never programmed in Haskell before but I've heard about that thing where IO is done using monads in order to abstract away the outside world. Since Haskell has no guaranteed order of execution, it's important that functions that perform IO operations somehow depend on the result of operations that should happen before. The abstraction using a monad probably makes this very convenient to work with. Also, in some languages with async programming, I guess you would get the same abstraction as futures, for free.
I only wish I could like the video as many times as I have watched it. What an incredible presentation and a simple explanation of such a feared topic. Thank you.
Hands down the most awesome explanation of Monads on RUclips
My experience as well, though I realise as much having already understood the concept via classic methods (see a book on Haskell), so I was like "Yep, that's totally it". I doubt it would have helped me if I had used it as tutorial material. Still, a stellar explanation
It turns out that we have been using monads without even knowing it for years.XD
Feel you
Agree
Maybe it was. I gave up when I heard the stupid music.
How on earth did you break the curse!? .... "Once you understand Monads you lose the ability to explain them"! 🤣
you have to trick a veteran functional programmer into helping you
if you start explaining monads to enough people that already understand them, eventually one will tell you 'oh you don't _actually really_ understand monads unless you understand…'
and suddenly you will feel this clearness in your brain
you can suddenly explain this concept and all of the useful ramifications
I think that's true for most coding problems ;)
This is greate video that explain how to use monads and how fo recognize them, but in true math style there is whole universe that you skiped.
@@GesteromTVAnd that's how he shoved it into a 15-minute video, and not a 60-minute lecture 😝
Monads are a brain virus which makes you believe in Monads
After maybe 10 years of periodically going back to the definition of monads, googling and still not understanding what the hell they are, you have done it! Thank you, one less mystery in life.
I watched this video last year, and this year, I already do not remember what it is. Time to watch this video again. :)
@@KingTheRat I did that recently too 😆
Yeah I saw the thumbnail on my feed and was like “ah, it’s that time of year again - time to learn what a monad is” 😅
I mean, "Its just a monoid in the category of endofunctors. What's the problem?" Scott Wlaschin also does a great job of explaining monads graphically with his "Railway Oriented Programming" talks.
But this was a great "part to whole" way to take a single use case and expand the concepts, step by step. Nicely done!
at 4:24 you have a bug. `wrapInLogs` is undefined. I think you meant to assign `a` to `wrapWithLogs`. Other than that... this is the best explanation of the monad pattern in JavaScript ever created on RUclips!
This seems like a very intuitive pattern but at the same time I never knew this could be so formalized. Thank you I learned a lot
I'm blind and you were able to describe your content without using this and that while pointing at places in the code. nice work.
bro WDYM YOU ARE BLIND AND WATCHING RUclips
@@steveloco1170 you do realize blind people live normal lives?
@@steveloco1170 main thing to know is "blind" is shorthand for visually impaired. Also you can learn from hearing too.
@@steveloco1170 not all blind people are completely blind. some at least have partial vision
I founded Vancouver's Functional Meetup which ran for 3 years...and we discussed monads a lot!! I had a lot of ongoing questions. I saw many presentations, yet I was always left wondering / wishing someone could actually show me a 'monad' rather than discussing the apparent philosophy or upper purpose! Finally, someone explained it with great code examples, which I could easily relate to Swift (my language) and completely and finally understand monads...I had assumed one didn't really need to know 'monads' to use them, and it turns out with arrays, maps/flatmaps, optionals, and even a plug in Then promise library - all these were monads of course and I didn't need to know one to use one...but your explanation nails it! Many thanks!!
Very good explanation, finally someone who's using a programming language which people who don't yet know what monads are can actually understand. Another good video on the subject is Brian Beckman's "Don't fear the Monad" which explains it in a more abstract way, but still using familiar terms.
Other videos, and especially Computerphile's video were completely inaccessible to me and left me thinking that I'd need to spend months studying category theory or at least read a book on Haskell before I could understand this concept. You and Brian made me realize that I had actually invented monads on my own and have been using them without knowing what they are.
I'm not familiar with this programming language. What language is this?
@@evanroderick91 I think this is typescript
@@evanroderick91 as mentioned before it is TypeScript: JavaScript but with types
I agree with you about video ‚Dont fear the monad’. Also explains it really well
It's funny you mentioned the computerphile video because I likewise, even in using monads wherever applicable, watched that video and felt like I understood it even less. Even funnier still is the disclaimer he gave of "well people criticize mathematicians for not being able to explain their concepts in relatable terms, but I think they should just get over it". And it's like... they will get over it, by just ignoring their work & having to rediscover it anyways in their own contexts.
This is my favorite explanation of Monads. Never saw such a simple yet concise explanation!
As someone who didn't know monads, this is an excellent video!
You started with an iterative approach on simple examples to give an intuition of why the idea of monads is useful. Then after having the intuition you give a more abstract, rigorous definition, along with real usages. I think I wouldnt have been able to understand the abstraction as easily if there wasnt the simple examples in the beginning. Then you give a summary to help remember the content of this video.
Overall I think the flow is great and the pace is just right. Sometimes I have to pause a bit to understand the code but I never have to think really hard to understand since the leaps in logic are always small enough. Thank you for making this video!
That was fun to watch. I've been writing rust for a good while now, so basically I've been using monads everyday all this time without knowing the concept's technical name. Watching you refactor bad typescript step by step into rust felt funny.
And this explains why don't understand Rust... I didn't understand monads!
One helpful trick that can help people adopt/be aware of a defined technique or pattern is to avoid giving it a name that sounds like a portmanteau of “moron” and “gonads”
@@ChrisD__ u cant understand rust, because rust is a political marxist cult of mentally ill activists
good luck in ur cult journey : )))
rust is literally trojan horse in linux kernel
Very interesting and new to me. One small thing; what you call a caret, < or >, is more properly known as an angle bracket when it is used as a delimiter. This is a caret: ^.
Yes, worst part(s) of the video, that.
Exactly! So painful to hear every time.
en.m.wikipedia.org/wiki/List_of_typographical_symbols_and_punctuation_marks
That's a circumflex.
This is a caret: ‸
I've been trying to understand monads for literally years and this explanation is what made it click.
Dude, I literally was using Optional without knowing what is it and how it actually supposed to be used. Huge thanks for explanation, found your channel today and already fallen in love with this and passwords videos!
Just for reference, in C# flatMap for lists (actually, all collections that provide IEnumerble interface) is SelectMany in Linq.
Future/Promise is the Task.
One more interesting thing - async/await (combined with Task) is very close by it’s behavior and purpose to IO monad (not mentioned here) - it “infects” function so you need to make functions that call it async (or, at least, return Task) as well. And it brings a big mindset shift, starts building understanding that we want to keep “IO monad” part as small as possible, splitting logic and IO. It will allow to write most of tests without mocks at all. And the rest that works with “outer world” (db, user input, other services calls etc) better to test with real interaction, e.g. integration tests.
The second part you wrote is potentially a good point, but I'm not convinced it's true. I know exactly what you mean by "infection" (I call it "prionic", and if someone doesn't know what a prion is, I go for ice-9 if they've ever read Vonnegut). But, I'm not sure it's really possible to have async in any kind of way where it doesn't "infect" all of its uppers.
Actually, callbacks in JS would possibly do this. But that's more a matter of using global state. Although, additionally, mutex's in general work this way. Thinking of reentrance patterns and such. Ok, you've convinced me. Yea I think this is a unique quality for Task. Even deeper, I think this may be a unique quality for Monads, overall. An accessory requirement for that to be the case is
BTW this is somewhat similar to the mathematical concept of "absorbing elements". I think Undefined, though, would most-closely mimic the concept of a synthetic (ie intentional union with) construction of a category with an absorbing element.
**An accessory requirement for that to be the case MIGHT be that it's a typed language. Though I think that's just a straight matter of "in order to be less immediately annoyed of categorically wrong implementations"
@@MrRedstonefreedom Typescript (in the video) gets compiled into normal Javascript, mostly by stripping away the types. So the async/Promise stuff usually becomes the exact same operations in Javascript.
For that matter, the node.js runtime has a utility function util.promisify() that converts a callback-using function into a Promise-using functions, and Promises have .then, .catch, .finally etc that resolve Promises with callbacks. The two are essentially equivalent.
A fellow c# bro.
first video that actually explains monads in sensible approachable way. thank u very much
Best video i have seen on this topic. Most videos start with explaining monads, monoids, and endofunctors and are completely overcomplicated. Starting with an easy to grasp example is way better
0:30 thanks a lot for using appropriate font size - readable at 360p.
it's such a small thing but makes such a huge impact on viewing experience.
Dude… years… years I tell you!!!! Why does everyone else suck sooooo bad at explaining this! Finally! I feel complete. Ty
Jesus, this is such a robust explanation. This could be watched every 3 months just to reconsider newly-encountered applicability. I already came to the same conclusions about monads in programming (as a design pattern, in any kind of paradigm or language), and done a lot of deep thinking, but even still, this is such a wildly useful video as a consolidation tool. You've given a lot of excellent visualizations that make aspects-management & its expression a lot easier.
Great explanation. I'm going to use this as a benchmark when I do actual education videos.
yeah, now that i think about it the oscilloscope video was quite similar to this one
I've always thought that the definitions people used are always more complex than they need to be. I'm glad you've managed to explain it in a way that feels like something a programmer would do
By programmer you mean code 🐒
@@AndreiGeorgescu-j9p i don't, and i'm a little confused at what you're implying. do you mean that no "real" programmer requires it to be explained like this? or that you don't think the code in the video is very good? please, enlighten me
@@erikgrundy a software engineer is supposed to be an engineer. An engineer uses math and science to solve real life problems. However "software engineers" are the only kind of engineers who hate math and science and think even simple basic math is "too complex" and are always looking for immediate answers on "how" to use something, with very little understanding of "what" something is or "why" it is.
The explanation above is terrible for very many reasons but mainly because he doesn't actually explain anything any what a monad actually is, it's just overly convoluted examples of what you can do with it which ironically is more complex than if somebody just explained what it is. You saying "feels like something a programmer would do" means code monkey because actual software engineers understand math and don't explain things this way
@@AndreiGeorgescu-j9ppretty elitist take in my opinion.
I think the video does a great job at highlighting the use and benefits of monads from a practical perspective. Many people, engineers and otherwise, benefit from illustrative examples as points to jump off of and then abstract.
You are free to complain about what you think engineers should and shouldn't do until the cows come home, I'm sure that's much more useful. Or, if you're so concerned about software pedagogy, why not put your money where your mouth is and make a guide yourself? But I understand, hiding behind cheap talk is much easier. These lazy software engineers, right?
@@AndreiGeorgescu-j9p in the same breath,
“engineers solve real life problems”
and
“they only care about *how* to use tools”
Using tools is what solves problems. It makes sense that engineers prioritise practical use over formal understanding. Save the high-level math for academia and research.
One thing I’ve noticed that is tricky is when you have a value wrapped in several monads. For example, if you have a value that is asynchronous and also can fail with an error. Then you have a value wrapped in a Future/Promise/Task as well as an Either.
Would love a video about how to deal with this complexity. How to traverse between different monad lands.
You’d probably pass one “runWithLogs()” into another, nesting the functions in the same way the types are nested
Yep, because Promise.then() has the same type signature and meaning as flatMap (or bind in monad). It transforms promise, using a function transforming wrapped value into a new promise.
@@ivanjermakov wouldn't this be trivially solved by back-tracking the function through the unwrap, since both monads are Generic in their implementation?
If you have a Future, what you probably have is something in the form of
future(optional(5)), which can also be expressed as a chain operation as:
let result: Promise = createOptional(5)
| .createFuture($0)
in which case you should probably be able to do something like `result.value.value` which should resolve without much problem:
Unfulfilled promise would nil
.none in the optional would also nil
Keywords are: monad transformers (more popular, safer to start with this) and extensible-effects (imho cooler) 😄
Very nice overview. One thing that could be helpful: flip the "normal" and "monad" land in your state graph (9:45) and then explain that "wrap" is sometimes called "lift".
Oh, so this is what they mean when they say that monads can be used to avoid side effects but can replicate the effect when you need to. Say for example, Instead of having a global array that is referenced and mutated by every function to concatenate logs into it, you can return a concatenated array as part of a monadic value, one that is created at the beginning of the chain and is returned as a value at every step of the way 'till the end. I mean, in this case we are using an array object, so it's probably still being referenced as a pointer, but still, the concept stands as it belongs to the chain of operations alone.
Thank you. this video is very practical, informative, and truly demonstrates what can be achieved with monad with actual example and not just the abstract concepts of it all. Best one yet that I've seen on RUclips. You've earned a new. subscriber!
I watched a bunch of talks about what monads were, but this was the first to make me realize that I actually wrote one unintentionally last year while trying to learn about design patterns
+1, this video taught me exactly what monads are from a practical standpoint. Thank you!
I loved this video. Would love to see some explanations on applicatives and functors as well and some fp-ts examples. The pipe and flow makes using monads and functors so nice
Never heard of this, but I can see how to make it in different programming languages now.
So it's just any helpful pattern to make code seem simpler while hiding busy works...
Knowing this I could make simple program documentations by mentioning for what I would need monad for in the functions...
Monad for value that logs itself, gives more programming simplicity, changes value using server connection, changes other program settings to make this one appliable...
I guess I could just add reusable lamda functions for functions which process those values, when they are attached to the function, so I need a function to attach them...
Now monads would be moddable by programmer aswell at the start of loading the program!
So now I got Function class and can create more usable functions for my needs at the start up with less code which behaviour I can change by attaching more functions in it.
I can add value to it, it get's processed by all lambda functions I've attached to it, but only one changes it and other uses it to do other stuff.
I create function at start up as static and give it a name and attach functions.
Now I could just call MyCustomStaticFunction(value) and all lamdas get called internally, perhaps knowing the old value and the new value..
I'd like to use preprocessor function so it would apply code in the binary release in that location instead of going back in memory to that function location, but it's ok for now...
Build is smaller, but code also runs slightly slower...
13:30 It's called flatMap not only for lists, but for any type that introduces structure. More generally, it's called bind or concatMap, it has a type signature of (struct: Struct, transform: (value: T) => Struct) => Struct, and means "Map a function over structure and concatenate the resulting structures". It is possible, because any monad must also be a monoid: define how to combine structures.
Basically, monad is a very general interface for flatMap.
By far the most amazing explanation i've ever read. Nice examples, made the concept a lot easier to understand!
I just made a monad this week without even realizing it, but I never thought about implement logging into it. I'll need to do that immediately because that would be extremely useful!
Dude. This was fucking sick, please keep producing videos like this. I think there's also a lack of beautiful visualisations for more advanced concepts (which makes sense because more people are going to be beginners).
Keep it up man, your animations are absolutely gorgeous :)
The fact that Swift has built in operator support for optionals using ? is so nice. It’s nice to be able to wrap up this behavior into a simple type declaration like User? (equivalent to Optional).
dart as well
It's not equivalent
Just to be nitpicky, the wrapper of the type is not a part of the monad.
The (in)famous sentence is true: A monad on A is a monoid of the endofunctors of A.
This means that the it is a F: A -> A, meaning that both the original object and the end object must belong to the same category.
In your examples, you are doing two different operations:
- An isomorphism, F: U -> W, where U are all the unwrapped objects and W are the corresponding unwrapped objects.
- A monad, G: W -> W, where the monad acts on any wrapped object and returns the same type of wrapped object.
Not that it is fundamental to program or anything, as most of the time combining both is the easiest solution (multiple times my functions accept different types for certain arguments and I internally transform those arguments into the type that I actually use in the function, like passing the name of a matplotlib cmap, and then I get the cmap, but also allowing to pass a cmap itself).
Another nitpick to make is that in pure functional programming, the "busy logic behind the scenes" cannot affect anything else other than the object being returned.
For example, if instead of adding the log to the object you wrote it somewhere else, that also wouldn't be a monad, even if that function would work exactly in the same way, being able to chain it as much as you want.
Because side effects have side consequences (for real), that goes outside of pure functions.
It’s some shady area tho, because adding to a list may have the side effect to increase its memory footprint, pure "pure" functions (on technical side) is barely relevant to most programmers.
@@gweltazlemartret6760 There's an interesting research language called Koka that uses an algebraic effect system instead of monads. I believe 70% of its stdlib has the "total" effect, meaning those functions:
* Are guaranteed to terminate
* Are guaranteed to not throw an exception
* Do not touch the heap
* Do not mutate any state
* Do not do IO
etc.
The total effect is even more restrictive than what a "pure" function in Haskell is. So the fact that a large portion of the standard library can be made of functions with the total effect shows that total pureness is somewhat relevant to programmers.
Dang. Within only 15 minutes you easily achieved what my professor in functional programming couldn't in an entire semester of 15 weeks lol.
No seriously, this video has to be the best explanation for Monads one can find on RUclips!
Hey, this is great! You've got a good way of explaining things using plain English and building concepts from a basic level.
i watch a lot of videos on monads and they always focus on the generic aspect of the monad wrapper, but really this video nails behavior aspects which is what really matters. you can even write monadic code in C using this examples and still have great value using it.
"A monad is just a monoid in the category of endofunctors, what's the problem?" for anyone wondering, was satire from the beginning (though the first part was taken from a math book, where the sentence does make sense in context).
One of the best videos on programming I've ever seen. Subscribed. Please make more!
You have quite a gift for education.
Thanks for taking time to explain this.
I’ve been struggling with the concept and think this may be the best presentation I have seen.
Every time I've heard an explanation of Monads I've been completely confused. As soon as I got to the part that mentioned Options, my Rust brain exploded and understood everything. Best video on the topic by far.
I kept seeing this video recommended to me, but I avoided it everytime thinking "this is gonna be too complicated, I'll watch it later when I have the time/energy." Glad I finally bit the bullet and watched it... was not disappointed. Fantastic explanation... please keep making videos like this!
This remembers me of my favorite feature of dart, Option (var?). It is beautiful how you can do more if you value can be null or have a value instead of always having to have a value.
Using (?) and (!) in dart makes the code much easier to read.
Impressive explanation. Quickly provided useful information that gives me better understanding of techniques I already use as well as new ones to adopt.
This is a great vid, but I'm not 100% sure about the example at 9:00. A lot of people will either:
- Include the conditional undefined return from the run function inside the JS methods
- Want to handle each undefined case slightly differently
In the former case, your code would be as clean as #2 without requiring the run wrapper. In the latter you'd end up with #1 where the run wrapper would just add clutter.
This video is a true triumph. Thanks so much for making it!
I recently discovered Effect-ts and was struggling to understand the basic concepts of it.
The docs don't mention mondas while explaining how the library works (due to a valid reason. Mentioning monads scares people!)
But this video explains it beautifully!
Thank you man! You got yourself a subscriber 😊
Thank you for this extensive explanation! 👍It's really useful as a background knowledge behind a ton of things in Rust that I learned, also because I have seen many people already talking about it there. Now I really understand it. 👏
But even in C#, a language in which I have worked for about 20 years now, I can relate several examples of monads as well.
A nice one are so called LINQ functions, for example SelectMany, which is basically the literal equivalent of your FlatMap example. LINQ is the name of the most important functional programming API in C# and DotNet.
Maybe it is also a good to mention that C# was really one of the first with the async await programming model, and it might even be the absolute first one. Though what you mentioned as Future or Promise are not the terms how they are used in C#, but what is used is generally Task or ValueTask, although other types can also be used sometimes.
Amazing work here. Turns out I've been partially harnessing the power of monads the whole time, but understanding how you can simply chain passed functions brings my software engineering understanding to a new level. Thanks for your effort in making this video Alex.
Nice combination of theory and practice.
So this is why Rust has std::option and encourages the use of some/none. Very informative. TYVM!
wow, first time I know monad so clearly. thanks and looking for future video like this. really good video.
This is the first video that 'shows' the thing by including 'how to' aspect. Best video I came across so far.
I don’t do a ton of programming with my job but I’ve just started a project that requires me to write a code that needs to handle a bunch of undefined data and I was wondering the best way to do that was, lucky I stumbled across this video in a perfect coincidence
Hey Alex, thanks for this video. I'm sending it to all my software engineer friends who have heard of Monads but have no interest in figuring out if its actually a good idea.
This is a nice abstraction, but we should be careful of making sure the performance hit is less than the benefit, and also be careful of unintended, "backstage" byproducts. We should use this pattern only when the advantage of using it would be tremendous, and not only for code to look a little nicer.
Can you give an example where it has any advantages at all? Other than being used to show off the giant size of somebody's intellectual balls, that is. ;-)
always know it's a great explanation when it starts with the problem being solved, thanks for the pleasant listen :)
I think a large part of the issue explaining Monads is the concept is actually so simple that there is a "why the special name?" question that makes people think it _must_ be more complex.
It is a basic function-application pattern, the likes of which you learn the first time you write an async event loop, or implement a DSL-FSM (See Greenspun's 10th rule). And yes, just like the y-combinator, or lambda calculus, it has a basis and explaination in math that makes it look more complex than it really is.
None of what you said is true
In Javascript Promises/Futures are an example of a Monad, and in that case then is flatMap/ >>=. However, Monads generalize the idea of promises/futures to be able to embed any language with any sort-of semantics into the language, so promises/futures are a way of embedding asynchronous computing into a stateful language and have it look like synchronous code just like monads are used to embed imperative/stateful languages into purely function Haskell. The thing about monads is that you have to know their 5 other definitions and many other examples to see how monads can shorten your code by. You have to know Monads other definition like flatMappables containers where flattenable containers are called Monoids, Mappables are called Functors.
I first grasped monads by thinking of them as piggybanks. The ceramic ones that you have to break.
This perfectly compliments that, thank you!
The fact I listened to that and connected on my own that futures might be a type of monad as well makes me somewhat proud.
If you wanted to implement logging quickly and cheaply, what you'd actually do is have a logger variable that gets passed by reference into anything that is going to log something, and the function does the log. One string construct-write, all writes going to the same place. The logger can even be something as simple as a string array.
8:02
This is a bit more understandable if your language can't pass multiple return values. I still think a templated stuct that has a bool and the raw type would be better, because you can just construct that as a return value and check the bool to see if the result is valid.
If you had a modern language that supported multiple returns, you could just return a bool and the raw type, and have a metaprogram check that the success parameter is checked if you need to.
8:22
Undefined is bad, always. Behavior and return values should always be defined in every case. Undefined behaviour is a bug.
8:50
In this example, if you use multiple return values, you can make the "Without Option" code much neater.
9:26
In my opinion, complex things should not be handled behind the scenes. That's how you get slow, inefficient, buggy code especially if you prematurely optimize.
To be fair, this is kind of an borderline case. Neatness and abstraction are valueable through apparent simplicity. The design decision every programmer has to make is "how much of a win am I getting here?" and consider alternative methods to achieve a similar result.
10:37
This makes it quite clear how much busywork the computer is doing in the background when the thing you're actually trying to do shouldn't require it. The only win you *might* get, in terms of speed, is if, in the case of Option, something might become nothing at any step of the process. Otherwise you're wasting cycles wrapping and unwrapping things.
This is busywork you're making the processor do that it didn't have to. This is SLOW.
11:58
I know enough about multithreading to know this isn't how you want to do it.
13:53
This is also slow, unless you're doing this in a functional language that can do all kinds of calculas on your program to make it go fast. I'd argue that functional laguages have many other downsides that make you not want to use them, but this isn't the place for that.
14:05
Let me rewrite this for you.
Monads are a slow design pattern because they let you chain operations with apparent simplicity while hiding work that the processor actually has to do behind the scenes.
Final conclusion: This is actually a very well put together and informative video, explaining a very abstract concept in very tractable terms. I would love to see more videos from you on more sensible design patterns. Despite all the hate for monads in this comment, you've done a very good job here Alex.
Flatmap on an array should not be implemented as a map+flatten, reasonable implementations just directly push the new elements onto the array
4:43 Thank you SO MUCH, seriously! When you said that it instantly clicked. This genuinely helped me so much, thank you!
If i'm seeing this right, it looks like a technique to bind operations that don't want to know about the all parts of a data structure to only the parts it wants to know about, in a way that's easy to extend both on the supported functions, and the underlying data structure. And then the broader secret work clicked
Bro, you're a legend. I've tried at least a dozen times before this to learn about monads. Wikipedia, googling, videos... was always left with the feeling that even though I didn't get it, the explanations were all trash. This video is so clear, I immediately understood the concept and how it was useful. And some old examples of monads that still rattled around in the skull suddenly made a lot more sense. Thank you.
This is a marvel of clarity.
I hope you're still making videos, you're excellent at explaining and teaching
great explanation. I will definitely use monads in my projects.
I've been doing this for years and just calling it good encapsulation and treating functions as a blackbox. Reduce how much the caller needs to know about the function and allow it to be a blackbox. Or rather I suppose, how to create the blackbox in the first place. Good to know the new vocab for it and this is a really good explanation, much better than I could give to new devs. I'd frankly send them to this video to learn the concept.
The way I understood it, monads require a logging of sorts no? Or was that just one use case for monad patterns
Nevermind it was just an example.
You've got no idea what you're saying and just saying things lol
This ain't it, chief.
Despite having already been exposed to monads through Rust's Option and Result types, your NumberWithLogs example gave me a better understanding of just what all I could use this pattern for. Thank you.
NumberWithLogs is not actually a monad, it has the wrong structure to be considered a monad.
Err, why function which does some math have to return logs :(
There is gotta be a better way to introduce logs into your code 👨💻
@@jfredericks309 can you elaborate on that?
@@itellyouforfree7238 as per the description in the Wikipedia en.m.wikipedia.org/wiki/Monad_(functional_programming) page for Monad, the NumbersWithLogs type is missing one of the defining elements that would make it a monad. There is no function as part of the type that allows different instances Of NumbersWithLogs to be composed. This is the bind or flatMap function which he references in the video but does not implement. You can see this where he stores the results of runWithLogs in variables. If he renamed runWithLogs to flatMap and made it a method on the NumberWithLogs type and removed the first parameter, then it would be closer to a monad. It might then look like this. wrapInLogs(5).flatMap(addOne).flatMap(square).flatMap(multiplyByThree). This would return an instance of NumberWithLogs which you would need to extract the result from. In fact if NumbersWithLogs was made generic say SomethingWithLogs, so the number parameters would all become T, then you have a Writer Monad.
@@jfredericks309 At 3:40 he writes the function `runWithLogs`, which is the "bind" function that makes `NumberWithLogs` a monad. There is no need to make it a "method", it makes no semantic difference. He intentionally avoided making `NumberWithLogs` generic to simplify the example. if anything, what is missing is that he never mentioned monadic laws. Those are what makes something a monad, not the name of the functions or whether it's a function or a method.
This is some good stuff. I'm also glad to see you have other videos. Hoping you get more subscribers, you deserve it
The best presentation on Monads I've ever seen... Thank you. Stand alone, does not reference external concepts. Great.
Having watched my fair share of videos, read articles and even delved into some theory behind lambda calculus and functional programming and still not understanding fully what monads are or how to even use them, I was reluctant to watch your video. "There's no way someone can explain monads to me in 15 minutes." I was gladly mistaken. You did the impossible and made monads click for me all the sudden, at least, in a practical way... so thank you very much
7:18 There is a type error in this code. The type of `transform` should be `(_: T) => Option`, and then the return type of run should be `Option` indicating that transform is allowed to change the underlying type. This is necessary for functions like `getPet` and `getNickname` in your next example.
Yep. A simple attempt to reconstruct the code in the example results in type errors. I'm grateful for the introduction, still.
Among all the functional programming videos in my feed this is the first one I understand something. Great video!
Great video! One small correction, though:
For the Option run method, you list that it only has one generic parameter. This implies the input type of the transform function must be the same generic type of the transformation's returned property. That's not true, since the getPet transformation transforms a User to an Option.
this is the best explanation of monads I've ever seen, thanks
I code mainly in Rust and PHP. They are both mixed paradigm languages, but I must say that using the Option type to guard against null values and the Result type to instead of Throwable+try-catch makes for much, much nicer code.
This is the best video explaining monads, thank you for the great yet simple explanation 😊
The absolutely best and extremely simple and unserstandable explanation of monad was done by Scott Walschin in his F# series. Absolutely must see!
Link?
@@henningtorsteinsen2169 that would be a good starting point: ruclips.net/video/KPa8Yw_Navk/видео.htmlsi=uabDLykGN5ZCkgbP
Never new the concept of Monads before watching this video but realized that I have been using this pattern without knowing its formal name. In java Optionals and Streams kind of serve the role of Monads only without the boilerplate. In spring reactor flux/mono also serves the role of monad. I am sure there must be more examples. I suppose that other languages also have features/libraries that abstract away the boilerplate of Monads. Sure, there might be cases when you would want to implement such a design pattern from scratch.
Still nice to see low-level implementation spelled out in JS.
THE BEST monads explanation, all other explanations I've read just made me even more confused.
At last! Great video thank you so much!Great namings, wrapper instead of unit and run instead of flatmap or bind to explain the concept before the terminology. Please make more videos like this
Definitely lives up to the title, thank you for making such a great explanation.
Excellent video again, I wish you best and hope to learn more intersting concepts from you Alex.
That's a convoluted way of describing a struct with methods.
I'm awake at 01:06 am and read the thumbnail as "Write better code with McDonalds"
Oh man, I feel like I've found a gold mine named Studying With Alex today. Thank you so much, Alex 😘.
I've never programmed in Haskell before but I've heard about that thing where IO is done using monads in order to abstract away the outside world.
Since Haskell has no guaranteed order of execution, it's important that functions that perform IO operations somehow depend on the result of operations that should happen before. The abstraction using a monad probably makes this very convenient to work with. Also, in some languages with async programming, I guess you would get the same abstraction as futures, for free.
This is an amazing intro in the sense that the title isn't even a clickbait! ;) Thanks for the video!
best thing I've watched in years! awesome job 👍👌👍👌👍
This is a pattern I use all the time. I'd heard the term "monad" but had no idea I'd been using them.
I only wish I could like the video as many times as I have watched it. What an incredible presentation and a simple explanation of such a feared topic. Thank you.
Dude your channel is a gold mine!!
Stellar presentation of monads! Thank you so much!
I would pay to get the music turned off. Very distracting. But very useful video, you explain it well.
That was seriouesly the absolute best intro to monads, thanks