[arciini]

As someone who has never really understood monads (or tried that hard to) but who has done a good amount of Javascript programming, I really like the description of a monad as a series of nested data structures describing the next steps of a project.

Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript. You're creating a data structure that you then attach a new function to execute with the results.

[compressedgas]

Not just similar. Promises are a monad. Though they don't strictly follow the monad laws as they are collapsing in JavaScript due to how Promise.resolve never allows a promise to resolve to a promise but only to the value of a promise.

[kqr]

I mean, as long as you have a flatMap/concatMap function JavaScript arrays are technically a monad too. But that is a practically meaningless thing to say.

What we talk about when we have about monads is the highly generic interface coupled with the highly generic combinators. This is not something shared by arrays and promises. In other words, none of them are monads in any practically meaningful sense.

[chriswarbo]

> I mean, as long as you have a flatMap/concatMap function JavaScript arrays are technically a monad too. But that is a practically meaningless thing to say.

It's not "practically meaningless"; it's depth-first-search logic programming (as per How to Replace Failure by a List of Successes https://rkrishnan.org/files/wadler-1985.pdf )

[kqr]

I'm not saying the operations themselves are meaningless. I'm saying that "being a monad" only means something beyond "supporting flatMap" when there's a library of generic monad combinators involved.

[dmitriid]

There's "Functional Programming Jargon" which explains all these concepts in Javascript: https://github.com/hemanth/functional-programming-jargon

[ReleaseCandidat]

> Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript.

Yes, and monadic code suffers from the same problem, that's why Haskell has do-notation

   do 
     b <- fun1 a
     c <- fun2 b 
     pure c   -- using Purescript's pure instead of Haskell's `return` 

instead of

   bind(fun1, (a) => bind(fun2, (b) => pure(b)))