Hacker News Reader

Comment by aikah | Hacker News Reader

So is it possible to explain monads with Javascript ? or even LISP ? seems to me monads == haskell so if one doesn't understand haskell one can't understand monads , cause all monad tutorials are written in haskell. So I ask , what is the point of learning what a monad is if i'm writing some Java ?

View on HN

Yes. Infact, a JavaScript Promise is pretty much the same as the IO monad* - the `then` method is a lot like `bind`. Promise.resolve is a lot like `return`

* almost the same to IO, because of recursive thenable assimilation, something that was added to promises but is totally short-sighted and unnecessary; and because promises are eager which means they don't represent the action to be executed, but the value of an already executed action

A concise and good explanation thanks.

Note that the word "monad" itself refers just to the "shape" of the object (and some rules about that shape), not the functionality.

For example, an array can be a monad if we define a bind method as map + flatten

  Array.prototype.flatMap = function(f) {
    return _.flatten(this.map(f))
  }

which works like so:

  allArticles = authors.flatMap(author => author.articles);

return would be

  Array.of = function(val) { return [val]; }

The shape (type) is the same:

the promise's bind (then) method takes a function that takes a value and returns a promise, and returns another promise

the array's bind (flatMap) method takes a function that takes a value and returns an array, and returns another array

the promise's return (Promise.resolve) method takes a value and wraps it in a promise

the array's return (Array.of) method takes a value and wraps it in an array.

You can get the array method types (shapes) from the promise ones by replacing promise with array (if you decide to give the methods the same name).

The implemented functionality, however, is vastly different.

I find it interesting that people complain about Haskell's monadic IO, and yet nodejs event-driven IO is arguably the same idea but without the syntactic sugar.

It is possible to implement monad-like behavior in javascript. But javascript does not have a type system to model them in.

Haskell is great because it's type system is rich enough to represent these concepts and not only that but enforce their usage (to a degree). Unfortunately this is like a drug, once you get a good dose of Haskell it's easy to crave an even richer type system with dependent types.

Yes, Fantasy Land is a specification of Monad (as well as other type classes) for JavaScript:

https://github.com/fantasyland/fantasy-land

For one example, Scala's `for` syntax is quite similar to Haskell's `do` notation, and lets you do some monadic things with `Option`, `Seq`, and other classes.

And then you can go much further into that world with the scalaz library.

This! Something that never fails to surprise me is that, while I have a mostly Java background for my day job, after we adopted Scala I often find it easier to understand/prototype a function in Haskell (my hobbyist language).

One of those things was Scala's `for` (and `flatMap`). It clicked for me once I noticed how similar it was to Haskell's `do` notation for Monads.

What's surprising to me is that it would seem Haskell has no right to be this helpful for understanding production code!

I enjoyed this explanation of monads in Ruby: http://codon.com/refactoring-ruby-with-monads

emacs lisp monad introduction:

https://www.google.fr/search?q=jvtoups+monads

I hope you know lisp just enough to adapt to the lisp-1 lisp-2 namespace.

Reply on news.ycombinator.com