Understanding Monads with JavaScript

Description

JavaScript has functional concepts. And a particularly tricky functional concept that people have trouble in understanding in the monad. In this session, we will talk about monads, how we can use them in JavaScript and what benefits they can bring.

Tip for presenter. Don't punish/bash/hit-with-force your space and enter keys. After I notice this once this is all I can hear... and worst of all I start anticipating for when will then next Hulk-smash spacebar keypress will happen. Just saying I'm sure I'm not the only one

It is possible to prove that sufficiently complex bureaucracy is not capable to takes care about the customers. There are too many problems with keeping the system alive. Customers are not necessary.

I see similar problems with complex and abstract descriptions of practical problems. There are so many problems with the concepts of Monads and similar abstracts objects that practical applications became not necessary and irrelevant. There are enough problems with the concepts of Monads by itself.

Do you need proof?

There are more than 10 presentations about Monads on Channel 9. I do not recall a single one which seriously discuss some practical aspects of that phenomena. There are not enough time to discuss such unimportant aspects of the problems in all these presentations.

I am not saying that this is bad.Abstracts concepts are also necessary. They makes our live more beautiful.

I was more putting forward the idea of computation expressions. In the c# part, this focused on binding Action<T> with a wrapper and it did so by taking in Action<T> and returning an Action<T>. While not explicitly following how monads are commonly explained, this does enable us to put some real world use cases of the concept to use (i.e. achieving composability, aspect orientation etc. without magical frameworks that do IL weaving).

On connecting the javascript part to the c# part: It might provide some more insight to show a c# version of the generic lift1 function and apply this function twice to lift the hello handle action to a secured and then a logged/secured hello handler. This might lead to even less boiler plate code for actually doing the logging and the security checks.

So I agree with Olmo that the c# part was more an application of the decorater pattern.

right in the middle you can see why dynamic typed languagues are just a pain. Any strongly typed languague won't have him made smarter about his add/add3 typo but the compiler would have him get it in no time .... and of course you can see the "JOY" of JS by adding and substracting strings and yield some kind of almost sensible output ... god this languagues is so ... argh

@philosopher: if you need practical aspects look at any of the LINQ casts here or elsewhere. Other examples would be the asynchronous workflows in F# (you can find a *inferior* version of this in C# too - there it's called await/async ), the IO-Monad in Haskell, testing with randomized data with QuickCheck/FsCheck, ...

That's the fun of this cat.theory stuff: it's so general that it's everywhere around you - even if you don't notice.