After around 10 videos I finally found an explanation on WHY monads are useful (and not how they are constructed. Thanks for putting a capital P on Practical Lesson!
Computerphile made a video about monads in which it is explained hoe monads are strictired, and then it's explained why they are structured with an example.
sure, A monad is a thing that binds or aids in sequencing of effects (not side effects) is more concise than anything else right? but the question is can *everyone* understand the statement or only a select few. lets face it a lot of us (including myself) need a book to do all this. Red book beats anything else I have seen.
Thanks Dan, great tutorial on Monads. Finally it makes sense to me, since I have been struggling the last couple of days and most examples getting to fast to abstract and/or being to mathematical. Great real life examples. Keep rocking.
I don't know Scala (yet), I don't know scalaz lib (yet), but still I could learn a lot from the code you represent to implement Monad's in other languages. Thank you very much! Lastly I think that Scala is the best path for Java programmer that wish to learn FP paradigm.
its not hard, they use fancy works liek monad etc, think of how to use it with map, flatmap. its easier then. read the book Programmin in Scala, lot of others are too cryptic.
@epiphoney Yeah he said he couldn’t resist because it was so easy to implement. He had no idea how many avoidable errors would arise from such an innocent seeming little reference.
I don't blame him. It really looks like a good concept at first glance. Even quite useful. Nobody could have predicted the amount of issues this would eventually bring.
Nice way to break down monads and for-comprehensions and how they interact, I have a much better understanding to apply these concepts generally. A question: what if I want to preserve the original exception all the way up to identify the root cause, and handle each one differently, but still want to recognize error handling as a cross-cutting concern?
I used to think the same thing but then realized that Scala, at the core, is in fact a rather simple language that allows you to express complex ideas. You could create monads in plain Java if you so wished, but it'd be even more complex and verbose.
What should be returned if you ask the first element from an empty list? An empty list? Null? What if the first item in the list was one of those? An exception? The Option monad described at 05:50 is similar to the Maybe monad in Haskell, which is very often used: what to return when you ask the index of a non-existing item in a list? -1 or null are possible, but it's simply much more clear if you say that the function "maybe returns an int".
This is a good presentation on how to use Scala's monadic comprehensions to clean up code. The problem you might want to address is that the performance characteristics of for comprehensions can be very, very *very* unpredictable. As such, it's taboo in many libs where performance is considered important. An alternative notation might avoid this.
at first glance, I am not grabbed by the underlying premise that this monadic approach de-uglifies the original early-return "problem" seems to me to replace bulkier, but trivial to grok code with shorter but denser non-trivial nuanced code in which both the definitions of the monads as well as their "implementations" need to be grokked
I'm currently wrapping my head around Scala. Nice video. However, the way I see it - it may more readable but you're actually writing more code by creating the extra monadic types. Am I missing something or is this a tradeoff that a developer has to consider?
The extra code is nice in that it provides types that the compiler can check and mostly verify that your code is following the constraint of the monad. also you only have to type the types up once then use wherever you need.
OMG. Such complexity from a would-be Java. Thats why i dropped Scala for Clojure. If something should be simple lets make it simple. Scala is not simple.
Ryan The Leach probably because it’s implemented OO, i.e. the methods are on the object, true monadic functions are top level and accept a monad instance. The context preserving behaviour of Option holds though. In java, Optional is not monadic as map does not preserve the “Some” context, ie if map on a Optional containing a value returns null then you get “none” ie the empty Optional
i watched until 20:00 and can no longer resist the temptation. just write def maybeCompute = foo.bar(_.baz).(_.compute) returns an Option[Int] or None, all problems solved, readable, no clutter at all.
Yeah, but these are Scala monads. I am still learning (which is why I'm watching the video) but I believe they are rather different to monads in a pure functional language like Haskell.
Nope, their usecase is very similar, scala just adopted them to be useful in a less pure language. It still is the same concept and the same usecase, Haskell is just more focussed on them because there are no other ways to achieve some things
I know this video is old, but the example pains me. C# for years now (and other languages for even longer), have the ?. operator, so you can just write foo?.bar?.baz?.compute(). I understand that this isn't the point of the video, but I wish the example was a bit more deep than something that can be expressed much more succinctly in other ways.
There's an alternative one(two)-liner which can be used in the Option (and others) example using flatMap. See gist.github.com/franza/96e7ba77aec237702ddc . For comprehension may be more readable for some people, but shorter example of flatMap looks more concise.
Юсуп Абдуллаев I think it comes down to whether you value readability over conciseness. In a large codebase shared with a lot of other people, I think readability should trump brevity and being idiomatic. Ultimately, the reason we write software is so that it solves a business problem and can be maintained for as long as possible with as little effort as possible. Looking at the problem from that perspective, I think the presenter's for comprehensions beat the use of underscores (which drove me batshit when I first started out with Scala) hands down.
This is a rather bizarre presentation of monads (from my perspective as a functional programmer) ... If you actually want to use monads, you'll need to have a look at the monad laws ... Is there some reason to use this rather 'exotic' formulation rather than defining the standard functions '>>= : m a -> (a -> m b) -> m b' and 'return : a -> m a'?
While informative, this is presented in the driest way possible, which makes it hard for me to remain interested throughout. I would suggest replacing the example code with concrete examples instead of the abstract "class A, ,method foo" structure. I would also suggest a commentator with a more compelling intonation. This is by no means a knock on the people who made this video, who obviously put a lot of thought and effort into it, and who are obviously very good at what they do. It should merely be seen as constructive criticism.
Crappy explanation - you explain all this as a monadic design - you don't explain functors, applicatives and then go to monads - you just explain flat map and map throw in M keyword to declutter completely useless code.
After around 10 videos I finally found an explanation on WHY monads are useful (and not how they are constructed. Thanks for putting a capital P on Practical Lesson!
Computerphile made a video about monads in which it is explained hoe monads are strictired, and then it's explained why they are structured with an example.
This video is more concise and clear than the damn Red Book (Functional Programming in Scala) ughghghghghghhhh
sure, A monad is a thing that binds or aids in sequencing of effects (not side effects) is more concise than anything else right? but the question is can *everyone* understand the statement or only a select few. lets face it a lot of us (including myself) need a book to do all this. Red book beats anything else I have seen.
Excellent. This is the most practical explanation of a Monad I've seen.
Thanks Dan, great tutorial on Monads. Finally it makes sense to me, since I have been struggling the last couple of days and most examples getting to fast to abstract and/or being to mathematical. Great real life examples. Keep rocking.
This is the best introduction I've seen around! Thank you so much 💜💜💜
I don't know Scala (yet), I don't know scalaz lib (yet), but still I could learn a lot from the code you represent to implement Monad's in other languages. Thank you very much!
Lastly I think that Scala is the best path for Java programmer that wish to learn FP paradigm.
I might have to watch this video 3 to 4 times to get hold of it completely!
but i think i still have some hope in learning scala!
its not hard, they use fancy works liek monad etc, think of how to use it with map, flatmap. its easier then. read the book Programmin in Scala, lot of others are too cryptic.
if ure stuck , ping me. Im not sure which part u don understand as it seems obvious to me.
Great description of a monad to help those from a OOP background!
"I call it my billion-dollar mistake. It was the invention of the null reference in 1965.
"
-- Tony Hoare
@epiphoney Yeah he said he couldn’t resist because it was so easy to implement. He had no idea how many avoidable errors would arise from such an innocent seeming little reference.
I don't blame him. It really looks like a good concept at first glance. Even quite useful. Nobody could have predicted the amount of issues this would eventually bring.
Very nice explanation of a confusing topic. Thank you.
Nice way to break down monads and for-comprehensions and how they interact, I have a much better understanding to apply these concepts generally. A question: what if I want to preserve the original exception all the way up to identify the root cause, and handle each one differently, but still want to recognize error handling as a cross-cutting concern?
I find this very useful coming from java! Thx a lot!
I used to think the same thing but then realized that Scala, at the core, is in fact a rather simple language that allows you to express complex ideas. You could create monads in plain Java if you so wished, but it'd be even more complex and verbose.
What should be returned if you ask the first element from an empty list? An empty list? Null? What if the first item in the list was one of those? An exception? The Option monad described at 05:50 is similar to the Maybe monad in Haskell, which is very often used: what to return when you ask the index of a non-existing item in a list? -1 or null are possible, but it's simply much more clear if you say that the function "maybe returns an int".
This is a good presentation on how to use Scala's monadic comprehensions to clean up code.
The problem you might want to address is that the performance characteristics of for comprehensions can be very, very *very* unpredictable. As such, it's taboo in many libs where performance is considered important. An alternative notation might avoid this.
If you used a slightly smaller typeface, you could make it possible to see more of the blank white background.
thanks, it's getting clearer
Finally, someone with a sane voice.
Yes, great explanation, it all makes sense now ! : )
Great voice!!! And great video!!!
What's the music in the intro and outro of this video? It's really nice.
at first glance, I am not grabbed by the underlying premise that this monadic approach
de-uglifies the original early-return "problem"
seems to me to replace bulkier, but trivial to grok code with
shorter but denser non-trivial nuanced code in which both the definitions
of the monads as well as their "implementations" need to be grokked
I would have loved you if you used smoke-white color against the white background
Hi, to be honest if you want to compare scala to java you should use java 8 and utilise Optional.of
jdk8 was release 2014
I'm currently wrapping my head around Scala. Nice video. However, the way I see it - it may more readable but you're actually writing more code by creating the extra monadic types. Am I missing something or is this a tradeoff that a developer has to consider?
The extra code is nice in that it provides types that the compiler can check and mostly verify that your code is following the constraint of the monad. also you only have to type the types up once then use wherever you need.
Thank you Dan
Really nice explanation.
Or simply use a color for the typeface that matches that of the background. Then it would simulate being able to see ALL of it.
You don't actually need all three returns in the second example.
FP -- composition is the universal pattern. :D
OMG. Such complexity from a would-be Java. Thats why i dropped Scala for Clojure.
If something should be simple lets make it simple. Scala is not simple.
Great video. But you didn't really explain WHAT a monad is. Just... how their use cases help.
nice presentation
Can you explain Either (Left or Right) monad?
What's a problem?
I thought option wasn't technically a monad?
Ryan The Leach probably because it’s implemented OO, i.e. the methods are on the object, true monadic functions are top level and accept a monad instance. The context preserving behaviour of Option holds though. In java, Optional is not monadic as map does not preserve the “Some” context, ie if map on a Optional containing a value returns null then you get “none” ie the empty Optional
Perfect
i watched until 20:00 and can no longer resist the temptation. just write
def maybeCompute = foo.bar(_.baz).(_.compute)
returns an Option[Int] or None, all problems solved, readable, no clutter at all.
Thanks! Sir
@SirTubelot you can play the video in 720 dpi in full screen mode.
Yeah, but these are Scala monads. I am still learning (which is why I'm watching the video) but I believe they are rather different to monads in a pure functional language like Haskell.
Nope, their usecase is very similar, scala just adopted them to be useful in a less pure language. It still is the same concept and the same usecase, Haskell is just more focussed on them because there are no other ways to achieve some things
You forgot to mention that Some(None) is None
I know this video is old, but the example pains me. C# for years now (and other languages for even longer), have the ?. operator, so you can just write foo?.bar?.baz?.compute(). I understand that this isn't the point of the video, but I wish the example was a bit more deep than something that can be expressed much more succinctly in other ways.
There's an alternative one(two)-liner which can be used in the Option (and others) example using flatMap. See gist.github.com/franza/96e7ba77aec237702ddc . For comprehension may be more readable for some people, but shorter example of flatMap looks more concise.
Юсуп Абдуллаев I think it comes down to whether you value readability over conciseness. In a large codebase shared with a lot of other people, I think readability should trump brevity and being idiomatic.
Ultimately, the reason we write software is so that it solves a business problem and can be maintained for as long as possible with as little effort as possible. Looking at the problem from that perspective, I think the presenter's for comprehensions beat the use of underscores (which drove me batshit when I first started out with Scala) hands down.
7 minutes in and I don't understand anything. I'll just stay safe with my C++
Check /watch?v=ZhuHCtR3xq8 (by Brian Beckman) or /watch?v=b0EF0VTs9Dc (by Douglas Crockford) for some explanations on monads.
This is a rather bizarre presentation of monads (from my perspective as a functional programmer) ... If you actually want to use monads, you'll need to have a look at the monad laws ... Is there some reason to use this rather 'exotic' formulation rather than defining the standard functions '>>= : m a -> (a -> m b) -> m b' and 'return : a -> m a'?
While informative, this is presented in the driest way possible, which makes it hard for me to remain interested throughout. I would suggest replacing the example code with concrete examples instead of the abstract "class A, ,method foo" structure. I would also suggest a commentator with a more compelling intonation. This is by no means a knock on the people who made this video, who obviously put a lot of thought and effort into it, and who are obviously very good at what they do. It should merely be seen as constructive criticism.
I hate foo bar baz
Crappy explanation - you explain all this as a monadic design - you don't explain functors, applicatives and then go to monads - you just explain flat map and map throw in M keyword to declutter completely useless code.
Simple solution bro: Create a better video or STFU.
terrible voice...