Monads and Gonads 

How it should be.

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.

He's definitely just trolling the audience.

+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."

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😂

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.

IT HAD TO BE SAID...

nomads?

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.

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 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-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.

+Krzysztof Wende Yes... but Erlang isn't really a "mainstream" language, is it?

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.

perhaps they are comonadic?

Nope. Coroutines are monads. Monad is a more general concept than a coroutine.

@@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.

Correct.

+Lao Tzu Bollocks.

I thought it was rather amusing.