_"After many years drinking the functional Kool-Aid, which had no side effects by the way"_ LOL I love that line so much This was so helpful, thank you so much!! This video explains it better than others have. Thank you!
This video is incredible. Most people view monads as a mathematical concept which only the most elite of programmers can learn which often leads to over-complicated explanations. This video shows a great representation about monads while being incredibly easy to understand.
This video is perfect, useful example, clear example and a touch of humor (that match the explanation, no less). You have broken the curse of the monad, as you can comprehend it as well as explain it. Congratulations and thanks a lot
So monads are actually an admission that sometimes an imperative program solves the problem better, and we produce some elaborate syntactical sugar to return them back into existence. For me it looks like the do-construction is ambiguous.
The best explanation of a monad in my opinion is a function that returns the same type of object that it is given. If you could use the result of a function as the input for the same function again, then the function is a monad. (Well and technically there must be an input which result is itself, because monoids require identity).
Hands down the best Monad explanation I've ever heard. I've heard 10+ minute technical ramblings on youtube that couldn't explain their point as well as this guy did in 1 minute with a movie and a short animated clip
It's hilarious that every single description given on monads, of which I've now watched or read ~20, will say: "people over-complicate monads, here's a simple explanation", but then go on to give a completely unique & different take on monads. If 20 completely different, yet correct, explanations (totaling over 10 hours of sense description) on a concept can be given... maybe it's not so simple :p This one added something great though, as they all do, so thanks. Monads are very very complex; you essentially must look at it from many different perspectives to fully grok their power as a pattern in programming & category theory. The maybe monad is straight forwards and probably most programmers have implemented it even without realizing. But it is complex even if you don't decompose it back into monoids, consider their relation, and then consider what happens with variants on type signatures, expressions, or generalities. And then considering what may constitute a monad (eg an object may implement it with a method that injects this as the first arg of the binary operation). And then there are extensions like if you want to define overridable default behavior, or optionalness of promotion into the monadic type (which, by necessitating kick-outs into global state in some way, are not possible in haskell but in others).
I don't understand, but based on what John Blow said about people explaining monads ("they are simple but every explanation i've ever come across is absolute overcomplicated crap") I believe that I would understand even less from any other explanation. (This is the first monad explanation that I've ever heard.)
Great video. As a side note, there is slight omission in the type of the prelude lookup function, and should be: _lookup :: Eq a => a -> [(a, b)] -> Maybe b_
Thanks for this video. It helped me to understand the basics. Just a heads up to anyone else watching that would like to try running the code in the video, the ifJust implementation should have an = instead of the -> on the last 2 lines.
How about starting with identity arrow in category theory the best way for mass effect the same time like this article helpful votes for mass of this server for it possible.
Funny never had any serious problems with Stack, but maybe I was just lucky. Now I'm making games and there's simply no libraries for that, so had to stop using Haskell. But there's just no language as fulfilling to work with as Haskell, so I'm pretty sure you will be back.
does 'if' exist in haskell ? (i ask because no 'if' in maths, no if (it's in logic where the 'if' exist), and haskell is know to be a maths-like langage)
If exists, but unlike in a language with statements, Haskell works in expressions, where everything has a value, so the if must have both possibilities - the positive and the negative case - and they must have (i.e. evaluate to) the same type, so the entire if expression has that type, and can be used as a value of that type in further expressions. So I can do `3 + (if x > 2 then 4 else 5)`, but I can't do `if True then 3 else "hello"`, because 3 and "hello" are of different types.
This is yet another example of the Monad Tutorial fallacy. Monads seem intimidatingly complicated at first, but they basically aren't. But they are a little bit. Just enough to cause every person who has ever understood them to try to make their own Monad Tutorial. But a tutorial is a simple explanation that anyone reading it can easily follow. And monads are a bit too complicated for that. Therefore, every single attempt at a Monad Tutorial fails. All of them. They're either technically inaccurate, or they're weird and difficult to follow. Monads in the abstract are a pattern with just the right complexity to make explaining them clearly using analogies both impossible, and yet tempting. If you don't need to know about monads, don't worry about them. If you need to use a specific monad in a specific programming language, look up what the syntax is for monads in your specific language, look up the details of the specific monad you're using, and then mess with it a bit until it clicks, which won't be long, as monads are pretty easy, and one specific monad is easier than monads in general. If you need to be able to write your own monads, just look up the formal definition of monads, and fiddle around with enough specific monads that you're comfortable using them. Then write a monad to solve your problem, if it actually would solve your problem. Learning monads is more like getting used to them than understanding them. There is no analogy of any real-world thing with monads that can possibly explain what they are. They're mildly complicated, but they aren't hard. Just fiddle around with them until you're used to them. But then you'll be tempted to try to explain them to others, just like everybody else, and your explanation will not be understandable except to people who already understand them, just like everybody else's explanations. Resist the temptation. Every Monad Tutorial ever written is either easy to understand yet incomplete, or it's technically correct and even harder to understand than monads themselves, because it's got exactly all the details of the technical definition wrapped into the analogy, plus also the extra work of converting the analogy thing to the technical details.
How is that possible that lookup can get 2 parameters. It’s just a function that can get one or not (at least by ur definition). Your definition of the first lookup is not correct. It should be: lookup :: Eq a => a -> [(a, b)] -> Maybe b Don’t know why someone wasn’t noticing before.
_"After many years drinking the functional Kool-Aid, which had no side effects by the way"_ LOL I love that line so much
This was so helpful, thank you so much!! This video explains it better than others have. Thank you!
This video is gold. I'm finally beginning to understand monads better.
The dude where's my car reference to explain a monad 🤣
This video is incredible. Most people view monads as a mathematical concept which only the most elite of programmers can learn which often leads to over-complicated explanations. This video shows a great representation about monads while being incredibly easy to understand.
This video is perfect, useful example, clear example and a touch of humor (that match the explanation, no less). You have broken the curse of the monad, as you can comprehend it as well as explain it. Congratulations and thanks a lot
Watched pretty much all the 'what is a monad' videos (apart from any where some guy is making a silly face on the front). This is a very good one.
So monads are actually an admission that sometimes an imperative program solves the problem better, and we produce some elaborate syntactical sugar to return them back into existence. For me it looks like the do-construction is ambiguous.
What my professor at a T10 University couldn’t explain in a 1 hour lecture, this guy explained it in 5 minutes. Thanks a ton.
The best explanation of a monad in my opinion is a function that returns the same type of object that it is given.
If you could use the result of a function as the input for the same function again, then the function is a monad.
(Well and technically there must be an input which result is itself, because monoids require identity).
Probably the most useful explanation of a monad I've ever seen. Thank you!
Hands down the best Monad explanation I've ever heard. I've heard 10+ minute technical ramblings on youtube that couldn't explain their point as well as this guy did in 1 minute with a movie and a short animated clip
It's hilarious that every single description given on monads, of which I've now watched or read ~20, will say: "people over-complicate monads, here's a simple explanation", but then go on to give a completely unique & different take on monads.
If 20 completely different, yet correct, explanations (totaling over 10 hours of sense description) on a concept can be given... maybe it's not so simple :p
This one added something great though, as they all do, so thanks.
Monads are very very complex; you essentially must look at it from many different perspectives to fully grok their power as a pattern in programming & category theory. The maybe monad is straight forwards and probably most programmers have implemented it even without realizing. But it is complex even if you don't decompose it back into monoids, consider their relation, and then consider what happens with variants on type signatures, expressions, or generalities. And then considering what may constitute a monad (eg an object may implement it with a method that injects this as the first arg of the binary operation). And then there are extensions like if you want to define overridable default behavior, or optionalness of promotion into the monadic type (which, by necessitating kick-outs into global state in some way, are not possible in haskell but in others).
This guy deserves a prize. Thank you so much
I don't understand, but based on what John Blow said about people explaining monads ("they are simple but every explanation i've ever come across is absolute overcomplicated crap") I believe that I would understand even less from any other explanation.
(This is the first monad explanation that I've ever heard.)
This is cool. I like going back-and-forth between practical and intuitive explanations like this, and the more formal ones.
Great explanation Stephen, much appreciated!
Thank you so much for such an amazing video. You explained it so well.
"he clearly forgot how to use the return operator" that line is when i realised this is my new favourite channel
Incredible video to get me started with monads!
and then....
Great video. As a side note, there is slight omission in the type of the prelude lookup function, and should be:
_lookup :: Eq a => a -> [(a, b)] -> Maybe b_
Thank you, this is really helpful!
Thanks for this video. It helped me to understand the basics. Just a heads up to anyone else watching that would like to try running the code in the video, the ifJust implementation should have an = instead of the -> on the last 2 lines.
Oops. I didn't run the animation through GHC
How about starting with identity arrow in category theory the best way for mass effect the same time like this article helpful votes for mass of this server for it possible.
This video blow my mind!
This was so cool! I wish you were a professor at my school - I literally go to Harvard 😂 but the teaching and humor doesn't compare to your style!
Super explanation.
I was blind but now I see.
So, a modad is just a state that is passed through a list of functions, with the output of each function becoming the state for the next function?
The joke is gold.
Funny never had any serious problems with Stack, but maybe I was just lucky. Now I'm making games and there's simply no libraries for that, so had to stop using Haskell. But there's just no language as fulfilling to work with as Haskell, so I'm pretty sure you will be back.
banger
Good video.
THANK YOU! this video is so valuable!
Very clear, simple explanation.
Can we have at least one Monet as well?
Monads didn't make enough of an impression?
Just read comprehending monads by wadler and that's it
And then?
What if you want to return a more informative error than just returning "Nothing"?
The Either typeclass is also a Monad that's designed to do this
does 'if' exist in haskell ? (i ask because no 'if' in maths, no if (it's in logic where the 'if' exist), and haskell is know to be a maths-like langage)
If exists, but unlike in a language with statements, Haskell works in expressions, where everything has a value, so the if must have both possibilities - the positive and the negative case - and they must have (i.e. evaluate to) the same type, so the entire if expression has that type, and can be used as a value of that type in further expressions. So I can do `3 + (if x > 2 then 4 else 5)`, but I can't do `if True then 3 else "hello"`, because 3 and "hello" are of different types.
This is yet another example of the Monad Tutorial fallacy. Monads seem intimidatingly complicated at first, but they basically aren't. But they are a little bit. Just enough to cause every person who has ever understood them to try to make their own Monad Tutorial. But a tutorial is a simple explanation that anyone reading it can easily follow. And monads are a bit too complicated for that.
Therefore, every single attempt at a Monad Tutorial fails. All of them. They're either technically inaccurate, or they're weird and difficult to follow.
Monads in the abstract are a pattern with just the right complexity to make explaining them clearly using analogies both impossible, and yet tempting.
If you don't need to know about monads, don't worry about them.
If you need to use a specific monad in a specific programming language, look up what the syntax is for monads in your specific language, look up the details of the specific monad you're using, and then mess with it a bit until it clicks, which won't be long, as monads are pretty easy, and one specific monad is easier than monads in general.
If you need to be able to write your own monads, just look up the formal definition of monads, and fiddle around with enough specific monads that you're comfortable using them. Then write a monad to solve your problem, if it actually would solve your problem.
Learning monads is more like getting used to them than understanding them. There is no analogy of any real-world thing with monads that can possibly explain what they are. They're mildly complicated, but they aren't hard. Just fiddle around with them until you're used to them. But then you'll be tempted to try to explain them to others, just like everybody else, and your explanation will not be understandable except to people who already understand them, just like everybody else's explanations.
Resist the temptation. Every Monad Tutorial ever written is either easy to understand yet incomplete, or it's technically correct and even harder to understand than monads themselves, because it's got exactly all the details of the technical definition wrapped into the analogy, plus also the extra work of converting the analogy thing to the technical details.
And then! And then! And then! And then! And then! And then! And then! And then! And then! And then! ....
She just enter in a infinite loop XD
Anyone who finds this video a bit hard to understand, start with this 3 minute video ua-cam.com/video/VgA4wCaxp-Q/v-deo.html
3:03
ifJust Nothing _ = Nothing
ifJust (Just k) f = f k
Yes.
association list = dictionary ?
A simple implementation of a dictionary. If the dictionary is big, you'd want to use something else
wtf is a maybe string
Either a normal string or nothing at all. It's Haskell's equivalent to a null pointer
@@stephen70edwards ok that's exactly what i imagined, great syntax actually :')
Well I'm pretty sure I could watch this at 0.5 speed and still have no idea WTF you are talking about. Back to the literature it is for me...
How is that possible that lookup can get 2 parameters. It’s just a function that can get one or not (at least by ur definition).
Your definition of the first lookup is not correct.
It should be:
lookup :: Eq a => a -> [(a, b)] -> Maybe b
Don’t know why someone wasn’t noticing before.
You're right. I copied the type signature incorrectly. I think the rest is OK
The more I study, the less I understand
Weird name for it
I'm too dumb to understand this.
what exactly dont you understand
@@christophhofer303 Everything
this toturial made no sense
Look deeper. Its learning hiw to hack