
Introduction to monads in JavaScript - Isofarro
http://blog.jcoglan.com/2011/03/05/translation-from-haskell-to-javascript-of-selected-portions-of-the-best-introduction-to-monads-ive-ever-read/
======
crazygringo
Can anyone tell me, in what real-world practical situation, this would be a
better design model than just normal IO-based logging?

Would there ever be a reason to do this in the browser? Or is this something
that would be more useful in a Node.js environment, and if so, when? Or is it
more theoretical than practically useful?

~~~
tmhedberg
If we look at an impure language like JavaScript through Haskell-colored
glasses, essentially every line of code in a JS program is automatically in
the IO monad. Haskell's bonus is that it gives you the frequently-exercised
option of writing code that's explicitly _not_ capable of doing I/O, simply by
omitting IO from its type, and having this constraint enforced by the
compiler. This self-imposed restriction helps avoid the numerous problems that
come along with uncontrolled side effects. But since you can't "escape" the IO
monad in JavaScript, there's not much point in making it explicit by doing
output in a visibly monadic way.

That being said, there are plenty of uses for the monad pattern outside of the
I/O domain. That's where a lot of emphasis is placed in Haskell, because
Haskell couldn't do I/O without monads, but there are tons of other useful
monads that have nothing to do with side effects. As the article illustrates,
two of these are Writer and List (written as [] in Haskell). Another massively
useful one is Maybe, which represents nullability, but by making it explicit
in a value's type we can avoid a lot of the problems that arise in "nullable
by default" languages.

In some sense, jQuery is an example of a monadic library, wherein the unit
function is $, which lifts its argument into the jQuery monad, and bind is
represented by the chain of method calls applied to that lifted value, each of
which returns a different value, still wrapped in the jQuery monad. I've been
told that LINQ in the C# world works similarly (in fact, there is supposedly a
lot of bleed-over of ideas from Haskell into .NET because Simon Peyton-Jones
works alongside some of the .NET language designers at Microsoft Research).

~~~
bluekeybox
> In some sense, jQuery is an example of a monadic library, wherein the unit
> function is $, which lifts its argument into the jQuery monad, and bind is
> represented by the chain of method calls applied to that lifted value, each
> of which returns a different value, still wrapped in the jQuery monad.

Aha. Thank you. Ever since I first learned about monads in Haskell (which is
not so long ago), I kept noticing examples of such patterns in some libraries
and was wondering whether it's only me who thinks there is a similarity.

~~~
saraid216
I've found it easiest to understand monads as "the theoretical basis behind
what a lot of languages think of as features". The purpose of understanding
monads feels to me as an exercise in returning to first principles.

Naturally, this has the usual consequence of first principles: a lot of things
that seem obvious are no longer Just There for you to Take For Granted.

That said, I'm not really prepared to say I understand monads. :P

------
tikhonj
If you like this sort of thing, check out the Arrowlets[1] library for
JavaScript. It uses "arrows", an abstraction in a similar vein to monads, to
make CPS functions and event handling neater (among other things).

[1]: <http://www.cs.umd.edu/projects/PL/arrowlets/>

From playing around with it, I think the arrows from that library are more
useful to practical JavaScript programming than monads.

~~~
luciferous
Since you're familiar with arrowlets, would you mind having a look at samsara?

[samsara]: <http://lcfrs.org/samsara/docs/dragndrop.html>

~~~
tikhonj
That seems cool--CoffeeScript's syntax is definitely better-suited for this
sort of thing than JavaScript's!

The main page says the library's in CoffeeScript, but the drag and drop
example uses JavaScript. Do you have a similar (or even the same) example in
CoffeeScript? I'd like to see what it looks like.

~~~
luciferous
There are two parts to example: the plain functions, and the composition.
CoffeeScript can make the plain functions look different, but the composition
is the strangest looking; I need to find a better syntax for representing a
directed graph in code, and CoffeeScript doesn't help with that part.

------
ibotty
re the comment in the original article about monadic javascript: take a look
at roy. <http://roy.brianmckenna.org>

------
plainOldText
Wow, I now understand monads. This article nailed it.

------
doublerebel

        ...it helps you spot accidental complexity...Being able to spot and extract
        such boilerplate can radically improve the clarity of your code.
    

I think a second version of this tutorial in CoffeeScript would really shine a
light on how CS is the best of JavaScript. Monads and FP are a breeze --
practically encouraged -- in CoffeeScript. It really removes the cruft of JS
syntax and lets me focus on well-designed code, and I've found myself using
similar patterns since I switched to CS. I code faster and (contrary to what I
expected) debugging is much easier.

------
tripzilch
I've read many attempts to explain Monads by now, but this is the first time I
think I actually "got" it. Well done!

