After a good amount of blog posts and other reads which failed it has been that video what has made me finally understand monads. Thanks!

Indeed! Just because you *can* record the audio with a potato, doesn't mean you *should*.

obviously some hiccups with the sound and so on, but I think this was a great talk and it sent me a bit further along my way. I'm haven't had the epiphany yet, but monads don't feel all that arcane any more. I just need some more practical experience!

Great talk. Please keep posting them -- they've all been good so far! Thanks for sharing!

Yes I believe I do matter.

Amazing talk but with few audio issues.

oh, the happy days before the widespread singular they

I think this video is well worth its time, in spite of the errors in it. I have seen more knowledgable presentations, but they all went much too quickly into generalisations. Like the title suggests, here it is made clear why understanding the topic is worthwhile (in terms of some specific cases contained in those generalisations). In my own novice observations though, beyond the first two examples the code doesn't actually make use of the theory of monads (if that's the right word). Compose and id are defined, but don't ever contribute to code that is executed. AddP of the third example and runIO of the fourth implement the parts of compose they need for themselves, with direct reference to the structure of the monad - which misses the point entirely. Without promising that this is the standard, correct way of doing things, I can at least say that it would be an improvement to e g implement addP as addP ns ms = ns >>= ( -> ms >>= (\m -> return (n+m))) In order to get that to work, P should either be defined as a monad along with the functions (>>=) and return, or just be replaced with [Integer] (since list is a monad already). I wouldn't call it elegant, but at least the interaction with the structure of the monad is now kept out of this function.

You should take the mike and shove / bind it to the range of whomever gave it to you, regarded as a function.

I think I'm going to read the article, this was very hard to follow. Obviously the audio, but the flow and continuity of the lecture and slides wasn't so great :/

the sporadic volume cuts make listening difficult.

That's good! I think, I got the point - for the first time!

Probably a great lecture, but impossible to comprehend. This was not merely bad audio from the mic. Some incompetent "sound engineer" was trying to process it... using a noise gate?

I have got it - but not because of this video! For me, this video was helpful - but it was also a VERY terrible waste of time. I have got thru this lengthy talk by at least 4 hours and tried to understand. Now, I understand why monads matter - even though I am NOT an english native. Now, I even understand how to implement a monad is haskell - but if you want to do it properly: Forget this video! I am writing this to save your time... 1) The code of Err.hs does implement a haskell monad - but the monad has NOT been used in the rest of the code. And if you dare to use the operator ">>=" and the function "return" the program will fail with "out of memory". Bye the way joinErr has not been used, as well. Hence, the example code is completly crap if you want to understand how implement monads in haskel. The corrected version is here: ----------------------------------------------------------------------------------------------------------------- -- Err Kleisli arrow example, -- derived and corrected from "Why Do Monads Matter?" London Haskell user group 24-Oct-2012 talk given by Derek Wright import Control.Applicative main = do print ((divBy 2 `composeErr` divBy 5) 2310) -- (2310 / 5) / 2 print ((divBy 0 `composeErr` divBy 7) 2310) -- (2310 / 7) / 0 => Divide By Zero Error!!! print ((divBy 5 `composeErr` divBy 11) 2310) -- (2310 / 11) / 5 -- Use division (by zero) as a function that -- could produce an error. -- (divBy 2) applied to 6 equals 3. divBy :: Integer -> Integer -> Err Integer divBy 0 y = Error divBy x y = OK (div y x) -- Add an Err data-type that can record Success / Failure data Err a = OK a | Error -- only 1 type of error but there could be more deriving Show -- Kleisli composition -- Use a type like (f . g) x :: (b -> c) -> (a -> b) -> (a -> c) -- but it is for Kleisli arrows (a -> Err b) composeErr :: (b -> Err c) -> (a -> Err b) -> (a -> Err c) composeErr f g x = do t1 (a -> Err b) -> Err b bindErr (OK x) f = f x bindErr Error _ = Error -- Prove we have implemented a monad by defining an instance of the type-class instance Monad Err where return = idErr (>>=) = bindErr {- If you want to avoid the following warning than you may implement the code below: divby.hs:31:10: Warning: `Err' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. -} instance Applicative Err where pure = OK Error _ = Error (OK f) something = fmap f something instance Functor Err where fmap f (OK x) = OK (f x) fmap _ Error = Error ----------------------------------------------------------------------------------------------------------------- Original confusing code here: github.com/londonhaskell/londonhaskell-2012-10-24-why-do-monads-matter/blob/master/Err.hs 2) There are better resources to understand monads in haskell. adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html#monads

Even as a native English speaker, parts of this video's audio are hard to decipher.

Horrible sound

such a bad presentation. do not waste your time with that crap. This guy is not only very poor prepaired, he seems not to know what he is talking about