Hahaha, but sad. I guess people never really understand what it is, just that they get used to using it. This could explain the existence of that curse.
10:51 'M' means 'large plastic bag containing...'. 't' means 'small bag of peanuts'. 'u' means peanut. So 'M t' means 'large plastic bag containing small bags of peanuts' and 'M u' means 'large plastic bag of peanuts'. The thing in the middle '(t -> Mu)' means 'open a bag of peanuts and empty it into a big plastic bag'. So the whole thing says: "take a large plastic bag containing many small bags of peanuts, open each bag of peanuts and empty it into another large plastic bag, and you will end up with a large plastic bag full of peanuts." No mention is made of what happens to all the empty leftover bags, but don't worry: they are automatically recycled (unless you're using C/C++).
+Daniel Earwicker Brilliant!This is the single must intelligent and comprehensible thing anyone has ever said about monads. Of course, you do know that volatilizing the the first Crockford law of monad pedagogy (maybe) considered harmful.
Or, in the case of the reverse state monad: "Open the bag waiting for peanuts and get its contents from the future. Then you will have had a small bag of peanuts to begin with."
"Caching is a deal with the devil: we have something which is likely to be wrong, but is sometimes right, and we don't know when it transitions from being right and wrong. With memoization, that never occurs: once it's memoized it's right and it will always be right" - D.C. 5:02
So basically, a monad is a box containing a value. You can pack a value into a box (return function) and you can unpack a box, transform the value in some way then pack the result into another box (bind function).
On Haskell: 8:10 _"And it kind of works.... except it's kind of hard"_ Is it really that hard though, or is it just a bit foreign to people who have learned to program in a different way? I found the elegance of the language a decent pay off to invest time into, and once it clicks it's really satisfying and not actually that hard to program in.
The notion that the IO monad is useless is incorrect for Haskell, though probably true for an untyped language like JavaScript. The IO declares that the computation performs an IO side-effect, and any other computations need to take this into account.
Ryan Riley Crockford explaining monads is like a taco expert explaining buritto wraps. "Burittos are just like tacos, but with a soft shell". Completely wrong in the eyes of someone who likes burittos, but a helpful pointer for a taco lover who has never tasted a burrito and desperately tries to imagine the concept. I think his perspective on the subject is valuable, although his lack of humility and fanboyism is quite off-putting sometimes.
Orian de Wit As a taco lover, this talk is relevant to me, can you explain what is a burrito? I agree with the arrogance part, but every technology needs a few fanatics or it won't gain traction, so I forgive that. This is great for those of us new to functional programming.
the best way I understand monads not using maths is: "A closed batch of code in which you have user defined functions going from pure functional into the monad and one single function to compute things from out of the monad within the monad (Bind function)". Simpler words: "Take a monadic value -> Bind it in order to "extract" (actually compose) the non-monadic value -> Use a function to make some computation on this value and be sure you function ends by wrapping the result into the monad -> Now you have a monadic value. Repeat from step one 'till you do all computations you desire" Not so dificult.. isn't it? I know I haven't talk about the return function or laws or whatever complicated concept. I got to explain this to my workmates, do you thing It is a good way to do so?
Promises were known to be nomads much time before Douglas realized it. For example, Don Syme implemented async computation in F# in nomadic style and he said he adapted the idea from Haskell.
Is it really true that "grown up programmers" don't use syntax highlighting? Or is it that dinosaurs learned programming before syntax highlighting was popular? I'm not a great programmer, but I can find the code I want much faster with highlighting. And maybe I'm just a n00b or something, but I actually like it being fun & colorful :)
"I don't use syntax highlighting because it's for kindergarteners and I'm an adult." This comment doesn't offend me, but I can see how it would alienate many developers. Crockford should've been humble and considerate of his audience instead of adding fuel to a meaningless flame war about which editor or coding style is "correct."
He's a dick. Pure and simple. Implying that people who use syntax highlighting are 4 years old. Then he goes on to say how great highlighting is... Utterly dumb guy
What a monad is (and this talk did a not so nice job explaining) is a type/object/whatever with 2 operations. `bind` which works by taking a function `a -> m b` and the monad object `m a` and combining them to produce a new monad object `m b` and then another function `inject` which sticks an arbitrary object `a` into a monad `m a`
9:00 _"In other to understand monads, you first need to learn Haskell and Category Theory"_ But does anyone actually say this? I've essentially never see people say this seriously. What's true is that it's worthwhile learning Haskell and Category Theory, so you probably should. I haven't seen many people say that's the only way you can learn about monads though. This whole "monads are hard", "monads require you to be a genius mathematician",... blah blah blah, that people recite endlessly has become such a silly and pointless cliche. If these "instructional talks" spent less time going on about ivory towers, how hard monads are, how everyone is claiming you need to be a category theorist to understand them (which no one is) and just got to the straightforward abstraction of the concept, with simplified discussion and then practical examples, people would actually learn about them way faster. We don't need this boring 15 minute fluff in every introduction to them. It's just weird.
First 12 minutes: Waste of time. 14:29: "Macroids" seem like an entertaining abstraction that just adds complexity comparable to Haskell's typeclasses. But then he surprises by showing that this enables some really neat syntax found in a lot of JavaScript libraries. jQuery is monadic? Cool! Unfortunately, he ends with the same fallacy as when you teach monads in Haskell: He ends up explaining a lot of syntactic convenience, rather than focus on the essential. He changes the subject 29 minutes in.
Everyone can use a computer, and some of those can program, but to be a computer scientist, you need math, because it is - like most other sciences when you go deep enough - based on math. So, it's like saying statistics or physics is hijacked by mathematicians. As for Linux, it only matters for efficiency on which level you abstract things (HW, OS, or language). I'm talking about ease of use. Finally, I'm not defending JS which isn't a lang which I particularly like, let alone a functional one.
He says that JavaScript was the first mainstream language to have closures, but Perl got there a couple years earlier. I wonder if he doesn't know that Perl has closures or he doesn't know that it's mainstream. I do get tired of language partisans (to include several of Perl's bigger cheerleaders) acting like they don't know there are any languages besides C (too low-level), Lisp (too weird, I suppose), Java (too verbose), and whatever their personal fave is.
I am still confused. This talk explains how we've been using monads and not knowing it, but I don't understand why I need to KNOW I've been using monads. In fact this makes them seem rather unremarkable and unimportant. Why again do we actually NEED them or need to know we're using them? When is it important to think in terms of Monads first, rather than accidentally using them?
Yea this talk was not very helpful. The problem is that he is trying to show monads through example (which I agree is necessary to get a feel for them) but then he gives examples that seem trivial (especially in a language like Javascript). He was mostly showing the identity monad, which is just normal function composition. To appreciate monads I agree that you don't need to know how to program in Haskell, but you do need to understand what pure functional programming is. That means no mutable state, no side effects, etc. So here is my explanation of monads for those people: Remember that the power of functional programming is all about the composition of functions. Monads are kind of a way to supercharge function composition so that it does something extra as well. The bind function (>>= in Haskell) is just this supercharged function composition with added behavior. Each type of monad is like a context that you can apply to a computation to tell it what that extra behavior should be when things are composed using bind. For example in the Maybe monad the context is "this computation could fail (eg. dividing by 0)". The added behavior, then, when we compose these functions using bind is "If any of these computations fail, the whole thing fails". This allows you to quickly assemble a long string of computations without having to check for nulls or errors at every step. In the List monad the context is "this computation could produce any number of results". The added behavior when we compose these functions using bind is then "take all of those returned values and pass them all through the next function". This allows you to model non determinism or simply string together a bunch of growing (or failing, it could return 0 results) computations without the need for nested looping or explicit recursion. In the State monad the context is "this computation relies on a state that might change after each computation". The added behavior when we compose these functions using bind is then "thread that state (which might have been changed) through from each computation to the next one for me". This allows you to do computations as if there was some global, mutable state while still remaining pure. In the IO monad the context is "this computation has side effects/is impure". The added behavior when we compose these functions can kind of be thought of as "I understand that this result is impure so go ahead and pass it along to the next function anyway". This allows you to identify and acknowledge exactly what parts of your code are impure and separate it from the pure stuff. So in general these things can be done without monads, but using them abstracts away a lot of boilerplate and confusing patterns. When you see a new monad, just think "what is the context of one of these computations" and then "what is the extra behavior that is added to composing these kinds of computations". Also, if you can think of another context like this and some added behavior that would go along with composing functions of that type, then you can write your own monad. One more thing that makes monads especially useful in actual functional languages like haskell is that haskell has a special notation for monads called do notation. This idea of passing the result of the previous computation to the next using bind is a way of sequencing computations in order and do notation allows you to write functional monadic code in a very procedural way. Under the hood, though, it is still functional.
Definitely one of the most interesting tech-talks I've seen in a while - very eye-opening inspiring stuff! One the concurrency part: I guess games in their essense must classify as turn based systems - Pondering how (if) one could use this approach for building a multi-threaded asynchronous game engine...
@FichDich InDemArsch So basically it's all just a psychological inability to admit that computers are not executing pure functions? Why are we wasting time on such personal psychoses?
This is yet another failed explanation of monads. Sorry. But it is. Monad is not an object. It is not an object with a bind method. This is an idea, first of all. An interface, if you wish. Monad is a way of describing a sequential computation within a certain context. This is a mathematical structure, first of all. Category theory helps a lot to remove the noise of the poorly designed language and look into a pure structure. I would disagree with the statement that Haskell doesn't always go right. GHC points exactly at the problematic point and sometimes may even suggest a solution. The message is not opaque, it says "argument a1 expected to have X type but it is of a Y type". A type system is the set of constraints on top of your untyped language that guarantees the correctness of your code.
Completely agree that this is a failed explanation. The main problem is that he even has not explained a problem. The 2nd problem is just he assumes a lot that people have understood him and continues to talk further loosing the people. No one in auditory asks the questions as no one wants to look stupid. I watched this ruclips.net/video/ZhuHCtR3xq8/видео.html video and I lost at 36.40. From this video I understood they wanna set of chained operations on an object. The only thing is not clear to me why is in RxJS in v 6. decided to go away from chaining and created the .pipe method ?
@@alexk6745 my assumption would be that '.pipe' puts emphasis on pure functions, rather than '.prototype' and 'this'. Once I took a glimpse at how would one build a custom operator. I am far away from being an expert at this, but it looked like a simple function composition. To be honest, I always try to avoid 'this' in JS as much as possible and from this premise '.pipe' looks fine to me.
My point is, concept of monads as presented here seems simple. I find it hard to believe that the only source of complexity (assuming one is familiar with functional programming) is (category) theory. Programmers don't need to study the theory of lambda calculus to be able to apply it, once it's explained to them another way, so I find it hard to believe that the same could've been done for monads but wasn't until Crockford. P.S. Apparently sequential execution can also be done using CPS.
60FPS in 2013? damn, talk about being ahead of time! Awesome. I noticed right away and was very pleasantly surprised! - ok, I'm 40s in, now let's see what is it actually about. XD
If you're trying to understand monads, look for Graham Hutton's videos instead. You probably don't *need* to learn haskell to understand monads, but I think learning both at the same time is actually easier than trying to learn monads in the context of javascript.
Fine, but if the title was "Monads and Gonads.js" we could have known this was going to be entirely based on Javascript before getting so far into the presentation.
I'd like to know in which direction you think programming languages will evolve. Did you watch the interview on channel9 he mentioned? Google/Bing for: "hewitt actor model channel9" and you'll find it.
@@agenticmark Yeah, I've just been using promises for monads actually. And I even created a validation system with promises github.com/jon49/MealPlanner/blob/master/src/app/utils/validation.ts#L74 It would be interesting to see how to make generators without function generators.
Why ignorance? It's math. The reason functional programming is important nowadays is scalability. If you continue using imperative programming languages in the concurrent age, I'm sure you're going to have a harder time with that, than I do with my side-effect evasion.
I like Crockford as a speaker and I consider myself to be a Crockfordian in many respects, but this time he got bamboozled by Haskell people. Monads are coroutines. Support for coroutines is available for almost any programming language except Java.
I don't think that he really wanted to talk about Monads, he actually took that topic for marketing reasons to attract people and talk about concurrency.
1. First write a mainfesto about the virtues of immutability. 2. Then invent mechanisms for escaping immutability. If there is a nonsense in the programming world for years, it is paradigm bigotry. If you live in a hybrid world, you should speak a hybrid language.
Programming languages, like everything else, should evolve on the basis of necessity. Trying to force some concept of how you would like things to be against how things really are, known to lead to disasters. You might be aware of a certain guy who wanted all human beings to be tall and blonde and what the result of that was.
> This talk is about doing absolutely nothing in a convoluted way. This talk is about hiding complexity. Complexity inevitably always happens, monads are way to deal with it. His reasoning is that monads are a tough subject to explain, but at the same time we're already using them. If your argument is that: hiding complexity does nothing practical, in the same way that refactoring doesn't add new features. I would agree with you, but you are also missing the point.
So, syntax highlighting is for kinder gardeners, but a pair of hanging parenthesis are confusing to the reader? Sometimes Crockford's way of thinking makes no sense to me.
Just check out Wikipedia's article about Lisp. And you're putting words in my mouth also. I've never said that "hiding complexity does nothing practical". What I'm telling you is that people smarter than you, me and the guy in this talk, already found out that functional programming in practice fails to hide anything.
Mathematicians used to and still have this weird ideal in which them and only them are the superior race that should be allowed to use computers. And about scalability: why don't you send a mass email to the linux kernel developers in which you announce your discovery that their product is not "scalable" and that it should be re-written on javascript.
He he, kids, play with your dynamic languages inside a browser. Thank God js is localized there. Just imagine a welding robot giving you a promise that it won't weld you. But then it says "I lied". Or a nuclear how about fission reactor's promise ? or just imagine Douglas convincing Linus to switch to BEAUTIFUL and POWERFUL monads for doing IO or implementing syscals :) LOL
I gave up after 25 min of this talk, none the wiser. The curse strikes again. I then scrolled down to Danny Gratzer's 2-line comment below and the concept clicked IMMEDIATELY. Thanks a million Danny ! I find it incredible how so many smart people do such an awful job explaining such a simple concept. I'd also like to mention that I found the title of the talk offputting, as well as the throwaway comment about huevos around the 12 min mark. Programming is a heavily male-dominated field, and stuff like this just adds to the feeling that it's a club for boys. "You too can learn about monads, if you've got the balls".
Hi Chris, you said "Programming is a heavily male-dominated fiel", and that is true, but there is not genitalia testing on the door, if women want to program they just have to pick a book about it or visit any number of online resources. Douglas Crockford is an old fart, by also his very smart and his contribution on creating JSON and educating people about programming is very important. And just to finish, it is the case that on any engineering-related subject men are the bast majority, but at least on the west all women are free to pick their major/career and they are very much welcome to join the ranks of the engineers.
I think choice of language is important and Nick raises an important point. However Crockford might be thinking a few steps ahead. He used the word "gonad", which actually refers to the ovaries in the female as well as the testes in the male, so it is entirely inclusive language. He also uses the term "huevos", which is slang for testes but literally means "eggs", the very type of cell produced by the ovaries ("huevos" is derived from the latin ova meaning eggs, as is "ovaries" of course). I suspect he intentionally chose these terms as satirical joke on gendered language.
You just did a tu quoque by implying a loaded question making an ad-hominem attack on your own strawman. Just to be clear, if a woman in tech says "I feel unwelcome in the programming community because the use of gendered slang and lack of inclusivity make it seem like a boys club," your answer is: "Your feelings are not important, and by the way we're not checking genitalia at the door so there's no problem." So basically, programming is a heavily male-dominated field, and you see no issue with this. But it's very important that we know how smart Douglas Crockford is.
This guy a just another victim of "modern" programming concepts. I really wish javascript and all the already-proven-useless-in-the-'70 ideas behind it would finally go away. But ignorance and narcissism keep bringing them back. This talk is about doing absolutely nothing in a convoluted way.
GoogleTechTalks: The only multi-billion dollar company sponsored talks by leading experts, filmed on VHS tape in a damp parking garage.
How it should be.
I think The Curse is holding...
Hahaha, but sad. I guess people never really understand what it is, just that they get used to using it. This could explain the existence of that curse.
link to Crockford's github project: github.com/douglascrockford/monad
i'm convinced that douglas crockford has figured out programming, this, and his frontend masters course have convinced me of this
10:51 'M' means 'large plastic bag containing...'. 't' means 'small bag of peanuts'. 'u' means peanut. So 'M t' means 'large plastic bag containing small bags of peanuts' and 'M u' means 'large plastic bag of peanuts'. The thing in the middle '(t -> Mu)' means 'open a bag of peanuts and empty it into a big plastic bag'. So the whole thing says: "take a large plastic bag containing many small bags of peanuts, open each bag of peanuts and empty it into another large plastic bag, and you will end up with a large plastic bag full of peanuts." No mention is made of what happens to all the empty leftover bags, but don't worry: they are automatically recycled (unless you're using C/C++).
+Daniel Earwicker Brilliant!This is the single must intelligent and comprehensible thing anyone has ever said about monads. Of course, you do know that volatilizing the the first Crockford law of monad pedagogy (maybe) considered harmful.
Or, in the case of the reverse state monad: "Open the bag waiting for peanuts and get its contents from the future. Then you will have had a small bag of peanuts to begin with."
Each time I listen to Douglas Crockford, I always get more inspiration on JavaScript.
This is a brilliant tech talk on Monads.
Doug said in a Google Talk "...go to Bing and Google for..."
He's definitely just trolling the audience.
"Caching is a deal with the devil: we have something which is likely to be wrong, but is sometimes right, and we don't know when it transitions from being right and wrong. With memoization, that never occurs: once it's memoized it's right and it will always be right" - D.C. 5:02
So basically, a monad is a box containing a value. You can pack a value into a box (return function) and you can unpack a box, transform the value in some way then pack the result into another box (bind function).
On Haskell: 8:10 _"And it kind of works.... except it's kind of hard"_
Is it really that hard though, or is it just a bit foreign to people who have learned to program in a different way? I found the elegance of the language a decent pay off to invest time into, and once it clicks it's really satisfying and not actually that hard to program in.
The notion that the IO monad is useless is incorrect for Haskell, though probably true for an untyped language like JavaScript. The IO declares that the computation performs an IO side-effect, and any other computations need to take this into account.
Ryan Riley Crockford explaining monads is like a taco expert explaining buritto wraps. "Burittos are just like tacos, but with a soft shell". Completely wrong in the eyes of someone who likes burittos, but a helpful pointer for a taco lover who has never tasted a burrito and desperately tries to imagine the concept.
I think his perspective on the subject is valuable, although his lack of humility and fanboyism is quite off-putting sometimes.
Orian de Wit As a taco lover, this talk is relevant to me, can you explain what is a burrito? I agree with the arrogance part, but every technology needs a few fanatics or it won't gain traction, so I forgive that. This is great for those of us new to functional programming.
Orian de Wit real tacos don't have "shells" but a tortilla, which is soft. but I get your point, I don't want to start a pointless flame war😂
the best way I understand monads not using maths is: "A closed batch of code in which you have user defined functions going from pure functional into the monad and one single function to compute things from out of the monad within the monad (Bind function)".
Simpler words:
"Take a monadic value -> Bind it in order to "extract" (actually compose) the non-monadic value -> Use a function to make some computation on this value and be sure you function ends by wrapping the result into the monad -> Now you have a monadic value. Repeat from step one 'till you do all computations you desire"
Not so dificult.. isn't it? I know I haven't talk about the return function or laws or whatever complicated concept. I got to explain this to my workmates, do you thing It is a good way to do so?
Promises were known to be nomads much time before Douglas realized it. For example, Don Syme implemented async computation in F# in nomadic style and he said he adapted the idea from Haskell.
nomads?
He talks not about programming without highlighting, he shows a really interesting convept of highlighting - scope-oriented highlighting.
Is it really true that "grown up programmers" don't use syntax highlighting? Or is it that dinosaurs learned programming before syntax highlighting was popular?
I'm not a great programmer, but I can find the code I want much faster with highlighting. And maybe I'm just a n00b or something, but I actually like it being fun & colorful :)
I mean, I judge my code off of how pretty it looks, so if you're a noob, I don't know where that puts me.
minimal highlighting is good. fruit salad highlighting is noisy
I've since made my editor only highlight strings and comments to differentiate anything that could look like code from actual code. I like it so far.
@@KevinBeal There's nothing wrong with syntax highlighting. Do whatever makes you productive.
"I don't use syntax highlighting because it's for kindergarteners and I'm an adult." This comment doesn't offend me, but I can see how it would alienate many developers. Crockford should've been humble and considerate of his audience instead of adding fuel to a meaningless flame war about which editor or coding style is "correct."
If he wasn't telling people what the One True coding style is, he wouldn't be Douglas Crockford.
Fair enough :)
He's a dick. Pure and simple. Implying that people who use syntax highlighting are 4 years old. Then he goes on to say how great highlighting is... Utterly dumb guy
***** " he takes himself too seriously, thus offending those who take their-selves too seriously."
Troll
***** "absorb the info" ... Haha. You're clearly a robot.
My piece of advice for confused ones: Read "Learn You a Haskell for Great Good!" chapters 11 - 13 instead trying to appreciate this talk
IT HAD TO BE SAID...
What a monad is (and this talk did a not so nice job explaining) is a type/object/whatever with 2 operations. `bind` which works by taking a function `a -> m b` and the monad object `m a` and combining them to produce a new monad object `m b` and then another function `inject` which sticks an arbitrary object `a` into a monad `m a`
9:00 _"In other to understand monads, you first need to learn Haskell and Category Theory"_
But does anyone actually say this? I've essentially never see people say this seriously.
What's true is that it's worthwhile learning Haskell and Category Theory, so you probably should. I haven't seen many people say that's the only way you can learn about monads though. This whole "monads are hard", "monads require you to be a genius mathematician",... blah blah blah, that people recite endlessly has become such a silly and pointless cliche.
If these "instructional talks" spent less time going on about ivory towers, how hard monads are, how everyone is claiming you need to be a category theorist to understand them (which no one is) and just got to the straightforward abstraction of the concept, with simplified discussion and then practical examples, people would actually learn about them way faster. We don't need this boring 15 minute fluff in every introduction to them. It's just weird.
The natural response to this talk is: do u have the COGONADS to understand COMONADS?!
19:00 is method chaining. I find it hard to believe that monads are simply objects/closures.
Helpful talk, but at 26:06 division by zero in JavaScript produces Infinity, not Nan...
First 12 minutes: Waste of time. 14:29: "Macroids" seem like an entertaining abstraction that just adds complexity comparable to Haskell's typeclasses. But then he surprises by showing that this enables some really neat syntax found in a lot of JavaScript libraries. jQuery is monadic? Cool! Unfortunately, he ends with the same fallacy as when you teach monads in Haskell: He ends up explaining a lot of syntactic convenience, rather than focus on the essential. He changes the subject 29 minutes in.
Everyone can use a computer, and some of those can program, but to be a computer scientist, you need math, because it is - like most other sciences when you go deep enough - based on math. So, it's like saying statistics or physics is hijacked by mathematicians.
As for Linux, it only matters for efficiency on which level you abstract things (HW, OS, or language). I'm talking about ease of use.
Finally, I'm not defending JS which isn't a lang which I particularly like, let alone a functional one.
Gotta love this man. A real living legend.
He says that JavaScript was the first mainstream language to have closures, but Perl got there a couple years earlier. I wonder if he doesn't know that Perl has closures or he doesn't know that it's mainstream. I do get tired of language partisans (to include several of Perl's bigger cheerleaders) acting like they don't know there are any languages besides C (too low-level), Lisp (too weird, I suppose), Java (too verbose), and whatever their personal fave is.
15:46 I want all my global level stuff to be white... TRIGGERING INTENSIFIES!
I am still confused. This talk explains how we've been using monads and not knowing it, but I don't understand why I need to KNOW I've been using monads. In fact this makes them seem rather unremarkable and unimportant. Why again do we actually NEED them or need to know we're using them? When is it important to think in terms of Monads first, rather than accidentally using them?
Yea this talk was not very helpful. The problem is that he is trying to show monads through example (which I agree is necessary to get a feel for them) but then he gives examples that seem trivial (especially in a language like Javascript). He was mostly showing the identity monad, which is just normal function composition. To appreciate monads I agree that you don't need to know how to program in Haskell, but you do need to understand what pure functional programming is. That means no mutable state, no side effects, etc. So here is my explanation of monads for those people:
Remember that the power of functional programming is all about the composition of functions. Monads are kind of a way to supercharge function composition so that it does something extra as well. The bind function (>>= in Haskell) is just this supercharged function composition with added behavior. Each type of monad is like a context that you can apply to a computation to tell it what that extra behavior should be when things are composed using bind.
For example in the Maybe monad the context is "this computation could fail (eg. dividing by 0)". The added behavior, then, when we compose these functions using bind is "If any of these computations fail, the whole thing fails". This allows you to quickly assemble a long string of computations without having to check for nulls or errors at every step.
In the List monad the context is "this computation could produce any number of results". The added behavior when we compose these functions using bind is then "take all of those returned values and pass them all through the next function". This allows you to model non determinism or simply string together a bunch of growing (or failing, it could return 0 results) computations without the need for nested looping or explicit recursion.
In the State monad the context is "this computation relies on a state that might change after each computation". The added behavior when we compose these functions using bind is then "thread that state (which might have been changed) through from each computation to the next one for me". This allows you to do computations as if there was some global, mutable state while still remaining pure.
In the IO monad the context is "this computation has side effects/is impure". The added behavior when we compose these functions can kind of be thought of as "I understand that this result is impure so go ahead and pass it along to the next function anyway". This allows you to identify and acknowledge exactly what parts of your code are impure and separate it from the pure stuff.
So in general these things can be done without monads, but using them abstracts away a lot of boilerplate and confusing patterns. When you see a new monad, just think "what is the context of one of these computations" and then "what is the extra behavior that is added to composing these kinds of computations". Also, if you can think of another context like this and some added behavior that would go along with composing functions of that type, then you can write your own monad.
One more thing that makes monads especially useful in actual functional languages like haskell is that haskell has a special notation for monads called do notation. This idea of passing the result of the previous computation to the next using bind is a way of sequencing computations in order and do notation allows you to write functional monadic code in a very procedural way. Under the hood, though, it is still functional.
Erlang had lexical closures ages before JavaScript. Even ages before NetScape existed
+Krzysztof Wende Yes... but Erlang isn't really a "mainstream" language, is it?
My advice: Going through some more monad-related material definitely helps to appreciate this talk! Really.
oh god i am noob
Definitely one of the most interesting tech-talks I've seen in a while - very eye-opening inspiring stuff! One the concurrency part: I guess games in their essense must classify as turn based systems - Pondering how (if) one could use this approach for building a multi-threaded asynchronous game engine...
I really admire those who understand this guy! Must be some kind of genius!
I admire those who can explain complicated topics easily. This is not the guy for that.
@FichDich InDemArsch Not sure why it's even a concept we need.
@FichDich InDemArsch So basically it's all just a psychological inability to admit that computers are not executing pure functions? Why are we wasting time on such personal psychoses?
This is yet another failed explanation of monads. Sorry. But it is.
Monad is not an object. It is not an object with a bind method. This is an idea, first of all. An interface, if you wish. Monad is a way of describing a sequential computation within a certain context. This is a mathematical structure, first of all. Category theory helps a lot to remove the noise of the poorly designed language and look into a pure structure.
I would disagree with the statement that Haskell doesn't always go right. GHC points exactly at the problematic point and sometimes may even suggest a solution. The message is not opaque, it says "argument a1 expected to have X type but it is of a Y type". A type system is the set of constraints on top of your untyped language that guarantees the correctness of your code.
Completely agree that this is a failed explanation. The main problem is that he even has not explained a problem. The 2nd problem is just he assumes a lot that people have understood him and continues to talk further loosing the people. No one in auditory asks the questions as no one wants to look stupid. I watched this ruclips.net/video/ZhuHCtR3xq8/видео.html video and I lost at 36.40. From this video I understood they wanna set of chained operations on an object. The only thing is not clear to me why is in RxJS in v 6. decided to go away from chaining and created the .pipe method ?
@@alexk6745 my assumption would be that '.pipe' puts emphasis on pure functions, rather than '.prototype' and 'this'. Once I took a glimpse at how would one build a custom operator. I am far away from being an expert at this, but it looked like a simple function composition. To be honest, I always try to avoid 'this' in JS as much as possible and from this premise '.pipe' looks fine to me.
My point is, concept of monads as presented here seems simple. I find it hard to believe that the only source of complexity (assuming one is familiar with functional programming) is (category) theory. Programmers don't need to study the theory of lambda calculus to be able to apply it, once it's explained to them another way, so I find it hard to believe that the same could've been done for monads but wasn't until Crockford.
P.S. Apparently sequential execution can also be done using CPS.
60FPS in 2013? damn, talk about being ahead of time! Awesome. I noticed right away and was very pleasantly surprised! - ok, I'm 40s in, now let's see what is it actually about. XD
This was a really great talk.
Who is forcing what and on whom? Giving a presentation is not force, but the opposite.
Wow - that was tough, but lovely to hear how modern JS remains
If you're trying to understand monads, look for Graham Hutton's videos instead. You probably don't *need* to learn haskell to understand monads, but I think learning both at the same time is actually easier than trying to learn monads in the context of javascript.
Fine, but if the title was "Monads and Gonads.js" we could have known this was going to be entirely based on Javascript before getting so far into the presentation.
Just looks like the decorator pattern with fluent interface to me...
Think I understand the term now, so "Monad" basically refers to function workflows utilising lexical closure?
Because javascript is much much more that just the stuff that makes a web page looks good.
Over 10 minutes of analogies about how easy we're going to make monads; 10 seconds on the slide containing all the meat.
I'd like to know in which direction you think programming languages will evolve. Did you watch the interview on channel9 he mentioned? Google/Bing for: "hewitt actor model channel9" and you'll find it.
JS now has generator functions so now we can have the do notation.
@@agenticmark Yeah, I've just been using promises for monads actually. And I even created a validation system with promises github.com/jon49/MealPlanner/blob/master/src/app/utils/validation.ts#L74
It would be interesting to see how to make generators without function generators.
Am I the only bothered by the hand on the wall?
Yep, great talk ! Very clear and understandable.
A monad is a monoid object in the monoidal category of endofunctors. Duh.
Why ignorance? It's math. The reason functional programming is important nowadays is scalability. If you continue using imperative programming languages in the concurrent age, I'm sure you're going to have a harder time with that, than I do with my side-effect evasion.
And what's wrong about that M&G in JS? It's like you say "I won't use that bicycle shed because of it's color".
How about the Either monad?
After hearing this talk my ovaries are now fully monadic.
perhaps they are comonadic?
Where are the GTAC 2012 vids?
this dude is an OG fosho!
I have a thing for older men talking about functional programming
oh. my. god. this is so amazing, just.. wow! you guys! wow!
I like Crockford as a speaker and I consider myself to be a Crockfordian in many respects, but this time he got bamboozled by Haskell people. Monads are coroutines. Support for coroutines is available for almost any programming language except Java.
Nope. Coroutines are monads. Monad is a more general concept than a coroutine.
I don't think that he really wanted to talk about Monads, he actually took that topic for marketing reasons to attract people and talk about concurrency.
Very poor explanation of Monads. It confused me more then it helped.
1. First write a mainfesto about the virtues of immutability.
2. Then invent mechanisms for escaping immutability.
If there is a nonsense in the programming world for years, it is paradigm bigotry. If you live in a hybrid world, you should speak a hybrid language.
I paused every time I didn't get it and now I do get it :)
apologies for switching from 'bicycle shed' to bicycles. but you could still get what I mean.
Spoken like a true boss
28:39 : "Go to Bing and Google for..."? :D
Correct.
The title of this talk should be revisited :(
What a load of Crockford.
Nobody is going to talk about the title?!
Wow, Godwin's law so soon? I guess we're done here. I was hoping for a constructive discussion. This is why we can't have nice things.
``Go to Bing and search for 'monad burrito'...'' LOL!
126635 subscribers and 28220043 video reproductions but Google Tech Talks doesn't have an avatar, come on guys, get your game together
Programming languages, like everything else, should evolve on the basis of necessity. Trying to force some concept of how you would like things to be against how things really are, known to lead to disasters. You might be aware of a certain guy who wanted all human beings to be tall and blonde and what the result of that was.
Too much background noise.
God damn this guy hates Haskell
it means "basic unit of reality" (google leibniz)
I've made several, which was very gratuitous of me, seeing what I was given.
> This talk is about doing absolutely nothing in a convoluted way.
This talk is about hiding complexity. Complexity inevitably always happens, monads are way to deal with it. His reasoning is that monads are a tough subject to explain, but at the same time we're already using them.
If your argument is that: hiding complexity does nothing practical, in the same way that refactoring doesn't add new features. I would agree with you, but you are also missing the point.
So, syntax highlighting is for kinder gardeners, but a pair of hanging parenthesis are confusing to the reader? Sometimes Crockford's way of thinking makes no sense to me.
Why is a Javascript guy doing monads?
28:38 "go to bing and google for monad burrito"
Just check out Wikipedia's article about Lisp. And you're putting words in my mouth also. I've never said that "hiding complexity does nothing practical". What I'm telling you is that people smarter than you, me and the guy in this talk, already found out that functional programming in practice fails to hide anything.
he is more famous than James Gosling now =*)
11:50 if you have the "huevos", you can
:D
Mathematicians used to and still have this weird ideal in which them and only them are the superior race that should be allowed to use computers. And about scalability: why don't you send a mass email to the linux kernel developers in which you announce your discovery that their product is not "scalable" and that it should be re-written on javascript.
He he, kids, play with your dynamic languages inside a browser. Thank God js is localized there.
Just imagine a welding robot giving you a promise that it won't weld you. But then it says "I lied". Or a nuclear how about fission reactor's promise ?
or just imagine Douglas convincing Linus to switch to BEAUTIFUL and POWERFUL monads for doing IO or implementing syscals :)
LOL
Excellent clickbait title Douglas! :)
Arthur Young led me here.
am so pro i cant make a txt editor with colors
I gave up after 25 min of this talk, none the wiser. The curse strikes again. I then scrolled down to Danny Gratzer's 2-line comment below and the concept clicked IMMEDIATELY. Thanks a million Danny ! I find it incredible how so many smart people do such an awful job explaining such a simple concept. I'd also like to mention that I found the title of the talk offputting, as well as the throwaway comment about huevos around the 12 min mark. Programming is a heavily male-dominated field, and stuff like this just adds to the feeling that it's a club for boys. "You too can learn about monads, if you've got the balls".
Hi Chris, you said "Programming is a heavily male-dominated fiel", and that is true, but there is not genitalia testing on the door, if women want to program they just have to pick a book about it or visit any number of online resources.
Douglas Crockford is an old fart, by also his very smart and his contribution on creating JSON and educating people about programming is very important.
And just to finish, it is the case that on any engineering-related subject men are the bast majority, but at least on the west all women are free to pick their major/career and they are very much welcome to join the ranks of the engineers.
So do you disagree with the notion that the language Crockford uses here might make women feel less welcome in the technology community?
Yes Nick, get over it, don't be so sensitive, your feelings are not that important
I think choice of language is important and Nick raises an important point. However Crockford might be thinking a few steps ahead. He used the word "gonad", which actually refers to the ovaries in the female as well as the testes in the male, so it is entirely inclusive language. He also uses the term "huevos", which is slang for testes but literally means "eggs", the very type of cell produced by the ovaries ("huevos" is derived from the latin ova meaning eggs, as is "ovaries" of course). I suspect he intentionally chose these terms as satirical joke on gendered language.
You just did a tu quoque by implying a loaded question making an ad-hominem attack on your own strawman.
Just to be clear, if a woman in tech says "I feel unwelcome in the programming community because the use of gendered slang and lack of inclusivity make it seem like a boys club," your answer is: "Your feelings are not important, and by the way we're not checking genitalia at the door so there's no problem."
So basically, programming is a heavily male-dominated field, and you see no issue with this. But it's very important that we know how smart Douglas Crockford is.
That was fantastic.
He lost me on the axioms slide...
Eventually it makes sense o_O
Tough crowd. Didn't hear much laughter at the jokes. Much more lively crowd here: /watch?v=dkZFtimgAcM
"I am more of a grownup" - anyone who says this is not one. Utterly useless talk thatdid not do what it promised.
Go to bing and google for monad burrito for the win
I cant think of anything dumber than explaining monads with js
Unfortunate name for this talk.
+Lao Tzu Bollocks.
I thought it was rather amusing.
Troll game is fire
This guy a just another victim of "modern" programming concepts. I really wish javascript and all the already-proven-useless-in-the-'70 ideas behind it would finally go away. But ignorance and narcissism keep bringing them back. This talk is about doing absolutely nothing in a convoluted way.