Details for people who care: 1. In general you can define monads on any directed graph supporting a composition rule. Programmers pick the directed graph to be types and functions. 2. One downside to writing things in terms of function composition is that it becomes harder to "name" all the relevant input and output variables. You can see this in the foldM example -- i didn't really write it in terms of my operator (>=>). There is an equivalent interface for monads which overloads function application instead of function composition. f(x) becomes x >>= f. This is what actually gets used in practice. 3. There are other operations which a monad is required to provide, but fundamentally they are there to make (>=>) or (>>=) more convenient. If you understand either of these functions, the others are easy.
Thank you for the explanation! The term "overloading function composition" and "f(x) becomes x >>= f" really helps my intuition toward understanding monad, coming from Java background.
"g composed with f in an overloaded way" - I'm still not really getting it, maybe if you had included an implementation of the Monad mechanism, so we could see how it worked abstracted from the examples...
This is a good video... but it really is no simpler or more intuitive of an explanation.. I understand Monads a little better... but only because it addition to this I've done my own reading and tried to learn bits and pieces of the underlying maths.
Great! So... In computer science tone，Monad is what take care of side effects automatically when you compose functions. In Math tone，Monad is what take composition in one category to composition in another category，in a reasonable way.
this is the best tutorial i've seen so far on monads. but i assume many programmers like me who've only just heard of this will still not see the big deal/benefits of using monads to their supposed advantage. it'd probably help if you gave a realistic example of why one would want to use monads. since we think it quite trivial to achieve in our own ways.
In imperative languages we don't need to smuggle in the side-effects which seems to be the main point of why monads are unavoidable in purely functional languages which don't allow for the creation of programs that actually interact with the real world, right?
So monads are generic containers whose prototype can be overridden by its usage in the program and implicitly declares "exceptional" behavior, including side effects that would otherwise not be possible to have in a purely functional programming language, and hides rules for handling such behavior inside of itself. Cool
So, a monad is essentially a special type that defines overloads for certain composition/calling operators that allows it to bake behavior (setup, teardown, error handling, etc.) into every function call using that type. Sort of like a decorator for types, but not really. Is my understanding correct?
Monad is a design pattern for a common generic wrapper type which can embellish any type with additional state and which also knows to unwrap itself - so that you can pass it several functions of typeA->MyMonad(typeB) and it will be able to chain those calls. Using a DB example: Take custId and find prodId. Take prodId and find latest patch. Here we use a Monad which is DBResult. So, my first function is findProdIdForCustId which takes int and returns DBResult. Again, my second function is findLatestPatchForProdId which takes int and returns DBResult. So, this DBResult monad knows how to unwrap itself. So, these functions can be chained to go from custId to DBResult. It can have some additional state like error code, in case something goes wrong in any of the functions that we are zipping through.
My problem with monads is that it's trivially easy to see what they do and it's not even that hard to use, but the how has a lot of hand waving. Furthermore, I'm not sure if it's just me but the idea overloading function composition makes very little sense to me someone who codes a lot in imperative and very little in functional. Function composition in my mind not in itself a function. And you have failed to show me how it can be overloaded I can see how addition can be defined for varying types but in the case of your composition you say we go from A to M(B) then another function goes from B to M(C) then you say our new composition goes from A to M(C) but how. You have to have some kind of way to deconstruct the monad M(B) into B such that I can be passed to the second function but that unpacking of the monad loses value that can't be passed back in as the second function does not take a monad input and thus cannot pass along the extra information we tagged onto B with our first function.
I don't understand. Why not just compose your logging function with each of the functions you are calling? Doesn't it do the same thing but in a simpler way? e.g. I have something like g(f(x)) and I want to log what happens after calling f and g. Why not write log(g(log(f(x)))) ? Or why not create a modified apply() function which is your logging function composed with apply?
I think composing a logging function between each of the functions that you are calling is exactly a monad - that's what "performing an additional computation on an intermediate value" means. You're basically describing a monad, just with a different choice of syntax.
I think you explained functors as a concept in programming instead of monads. Monads are about nested computation and hiding implementation details of this nesting so that you can code in a way that it looks like a pipeline.
Partially. The important phrase was "in such a way that a computation is performed on the intermediate value". Perhaps I should have emphasized that point more. Either way, I tend to think of a functor as the formal definition of an analogy.
Most of it makes sense, but I don't understand what overloading is lol. Also, what's the audience of this again? What exactly is a beginning programmer? I've had 2.5 years of computer science courses and found this new.
Basically overloading is when you give multiple definitions for a function with the same name (but different input types). The thing thats kind of weird for a C++ person or a C# person is that for types M, I want to overload function composition with respect to the M, not the A. To my knowledge, you can't actually do that in C++ or C#. Haskell has type classes and polymorphism over higher kinds, which makes saying these things a lot easier. I know people write monads in languages like C# but you have to fight the language to make it work.
Yet another tutorial in which the author didn't bother writing a simple running example in a non-obscure programming language. I swear to God, what is wrong with people??
he took the factorial example which is one of the simplest examples TO DATE because the code itself looks like high-school maths. There is almost no keyword, no weird pointer arithmetic or anything aside from the classic list of integers you learn about in the most beginner friendly coding tutorial of any language and yet you complain that it's obscure???? You don't want to learn, you want spoon feeding.
@@jyrikgauldurson8169 All that sentence means for beginner purposes is "a monad is a monoid of contexts". Which is a totally fair way of thinking about it, given you know what a monoid is. You can promote a context-free value into a context using return (thats like the unit of the monoid) and you can flatten a context of contexts into a single context using join (thats like the multiplication). So the most annoying thing about that meme is that its actually a good and intuitive way of thinking about it, but people just went "lol big words". I didnt explain it that way only because it doesnt give as strong of an intutition on how programmers use monads.
Aah so it's like that, huh. I understand everything now. Only it's still not quite clear how are monads different than nomads.
Details for people who care:
1. In general you can define monads on any directed graph supporting a composition rule. Programmers pick the directed graph to be types and functions.
2. One downside to writing things in terms of function composition is that it becomes harder to "name" all the relevant input and output variables. You can see this in the foldM example -- i didn't really write it in terms of my operator (>=>).
There is an equivalent interface for monads which overloads function application instead of function composition. f(x) becomes x >>= f. This is what actually gets used in practice.
3. There are other operations which a monad is required to provide, but fundamentally they are there to make (>=>) or (>>=) more convenient. If you understand either of these functions, the others are easy.
Thank you for the explanation! The term "overloading function composition" and "f(x) becomes x >>= f" really helps my intuition toward understanding monad, coming from Java background.
I heard you like composition
So we composed your composition with a composer so you can compose while you compose
"g composed with f in an overloaded way"
- I'm still not really getting it, maybe if you had included an implementation of the Monad mechanism, so we could see how it worked abstracted from the examples...
This is a good video... but it really is no simpler or more intuitive of an explanation.. I understand Monads a little better... but only because it addition to this I've done my own reading and tried to learn bits and pieces of the underlying maths.
Aah so it's like that, huh. I understand everything now.
Great! So...
In computer science tone，Monad is what take care of side effects automatically when you compose functions.
In Math tone，Monad is what take composition in one category to composition in another category，in a reasonable way.
this is the best tutorial i've seen so far on monads. but i assume many programmers like me who've only just heard of this will still not see the big deal/benefits of using monads to their supposed advantage. it'd probably help if you gave a realistic example of why one would want to use monads. since we think it quite trivial to achieve in our own ways.
In imperative languages we don't need to smuggle in the side-effects which seems to be the main point of why monads are unavoidable in purely functional languages which don't allow for the creation of programs that actually interact with the real world, right?
So monads are generic containers whose prototype can be overridden by its usage in the program and implicitly declares "exceptional" behavior, including side effects that would otherwise not be possible to have in a purely functional programming language, and hides rules for handling such behavior inside of itself.
Cool
damn it just made sense for me
AHH!!! Customised function composition!!
After giving it some thought I've come to the conclusion that this video has got to be a joke.
After watching it I felt like it had to be a joke too. Because of how it shows how hideously bad most people explaining monads are at it.
So, a monad is essentially a special type that defines overloads for certain composition/calling operators that allows it to bake behavior (setup, teardown, error handling, etc.) into every function call using that type. Sort of like a decorator for types, but not really. Is my understanding correct?
This is the best explanation of monads I have ever seen.
(And I have done a few Haskell turorials, and I know a few basics of category theory.)
You had me at "Computerphile."
How would you explain that to a FORTRAN programmer?
So it's like a decorater? Don't hit me if Im wrong!
i had exactly the same idea
This comment was the final piece I needed to finally get this concept. Apparently I have been ruined by OOP.
Excellent video, more FP topics should be simplified like this if FP is to become mainstream.
Monad is a design pattern for a common generic wrapper type which can embellish any type with additional state and which also knows to unwrap itself - so that you can pass it several functions of typeA->MyMonad(typeB) and it will be able to chain those calls. Using a DB example: Take custId and find prodId. Take prodId and find latest patch. Here we use a Monad which is DBResult. So, my first function is findProdIdForCustId which takes int and returns DBResult. Again, my second function is findLatestPatchForProdId which takes int and returns DBResult. So, this DBResult monad knows how to unwrap itself. So, these functions can be chained to go from custId to DBResult. It can have some additional state like error code, in case something goes wrong in any of the functions that we are zipping through.
My problem with monads is that it's trivially easy to see what they do and it's not even that hard to use, but the how has a lot of hand waving.
Furthermore, I'm not sure if it's just me but the idea overloading function composition makes very little sense to me someone who codes a lot in imperative and very little in functional. Function composition in my mind not in itself a function. And you have failed to show me how it can be overloaded I can see how addition can be defined for varying types but in the case of your composition you say we go from A to M(B) then another function goes from B to M(C) then you say our new composition goes from A to M(C) but how. You have to have some kind of way to deconstruct the monad M(B) into B such that I can be passed to the second function but that unpacking of the monad loses value that can't be passed back in as the second function does not take a monad input and thus cannot pass along the extra information we tagged onto B with our first function.
2:33 There is a missing closing round bracket in the main's return line.
I don't understand. Why not just compose your logging function with each of the functions you are calling? Doesn't it do the same thing but in a simpler way?
e.g. I have something like g(f(x)) and I want to log what happens after calling f and g. Why not write log(g(log(f(x)))) ?
Or why not create a modified apply() function which is your logging function composed with apply?
I think composing a logging function between each of the functions that you are calling is exactly a monad - that's what "performing an additional computation on an intermediate value" means. You're basically describing a monad, just with a different choice of syntax.
I think you explained functors as a concept in programming instead of monads. Monads are about nested computation and hiding implementation details of this nesting so that you can code in a way that it looks like a pipeline.
Partially. The important phrase was "in such a way that a computation is performed on the intermediate value". Perhaps I should have emphasized that point more. Either way, I tend to think of a functor as the formal definition of an analogy.
Highly decent
You need to watch this video without looking at the screen. Like a audiobook. Thats much better to understand.
Then it wont be "watching". Instructions are not clear. :)
Most of it makes sense, but I don't understand what overloading is lol.
Also, what's the audience of this again? What exactly is a beginning programmer? I've had 2.5 years of computer science courses and found this new.
Basically overloading is when you give multiple definitions for a function with the same name (but different input types). The thing thats kind of weird for a C++ person or a C# person is that for types M, I want to overload function composition with respect to the M, not the A.
To my knowledge, you can't actually do that in C++ or C#. Haskell has type classes and polymorphism over higher kinds, which makes saying these things a lot easier. I know people write monads in languages like C# but you have to fight the language to make it work.
Oh. I'm familiar with that concept; just forgot the word for it. (I program in java)
Great explanation. Please do a detail explaining of the monad you shown.
Yet another tutorial in which the author didn't bother writing a simple running example in a non-obscure programming language. I swear to God, what is wrong with people??
he took the factorial example which is one of the simplest examples TO DATE because the code itself looks like high-school maths.
There is almost no keyword, no weird pointer arithmetic or anything aside from the classic list of integers you learn about in the most beginner friendly coding tutorial of any language and yet you complain that it's obscure????
You don't want to learn, you want spoon feeding.
amazing description, extremely clear. thanks
Whut is this I am twelva
Monad in one sentence(for thoes who know some mathematics): Monoid in the category of endofunctors :)
this meme again? I doubt you understand category theory.
@@jyrikgauldurson8169 All that sentence means for beginner purposes is "a monad is a monoid of contexts". Which is a totally fair way of thinking about it, given you know what a monoid is. You can promote a context-free value into a context using return (thats like the unit of the monoid) and you can flatten a context of contexts into a single context using join (thats like the multiplication). So the most annoying thing about that meme is that its actually a good and intuitive way of thinking about it, but people just went "lol big words". I didnt explain it that way only because it doesnt give as strong of an intutition on how programmers use monads.
and , your intro. takes almost 1 minute...
What a bunch of useless nonsense :D