
Maybe Monads Might Not Matter - DanielRibeiro
http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html
======
ekidd
If you're designing a programming language, and you're planning to include
monads solely for the sake of IO, the author has a point: Monads are a very
complex way to perform IO, and you're better off with a simpler abstraction.

But monads are good for dozens of other things, including Bayesian
inference[1], computation with optional values, list comprehensions, software
transactional memory, quantum mechanics[2] and (to geek out a bit) anything
that involves defining a lambda-calculus analog over a topos. Any time your
problem domain includes a bunch of hairy matrix math, there _may_ be a lovely,
intuitive formulation using monads.

Now, if you're never programmed in Haskell, or if you've stuck to the IO
monad, you may not understand why monads are a powerful way to tackle certain
kinds of problems. But if you've never used monads in anger, how do you
whether or not they're a useful tool?

If you want a relatively programmer-friendly language that supports monads,
check out Scala's 'for' loop. It looks like a list comprehension, but it gives
you about 90% of what you want from monads in practice.

[1] Here's an article I wrote on probabilistic programming with monads:
[http://www.randomhacks.net/articles/2007/02/22/bayes-rule-
an...](http://www.randomhacks.net/articles/2007/02/22/bayes-rule-and-drug-
tests)

[2] Here's a much cooler article on quantum mechanics with monads:
[http://blog.sigfpe.com/2007/03/monads-vector-spaces-and-
quan...](http://blog.sigfpe.com/2007/03/monads-vector-spaces-and-quantum.html)

~~~
aristidb
There's an often-discussed (hypothetical) extension to Haskell's list
comprehensions called Monad comprehensions. I suppose that would be similar to
Scala's "'for' loop".

But really, the difference between 'do' notation and a syntax based on list
comprehensions is not that big.

Compare:

[(x, y) | x <\- [1 .. 10], y <\- [1 .. 10]]

vs

do { x <\- [1 .. 10]; y <\- [1 .. 10]; return (x,y) }

The main difference is that it uses return (which is implicit in the
comprehension syntax), and the final element in the do syntax is pushed into
the first position in comprehension syntax.

(Another alternative would be liftA2 (,) [1 .. 10] [1 .. 10].)

------
kenjackson
This author seems to make several mistakes.

First believing that async calls to actors with side effects helps reasoning.

Second he conflates Haskells exposure of monads with the math of monads.
Haskell just makes more explicit (and provable) what other systems indirectly
model (often times muddling the ability to reason over it).

------
ghc
This post is full of spurious reasoning. Haskell's monads are mainly (ignoring
the specifics of IO) syntactic sugar for a series of lambdas akin to a series
of asynchronous functions linked via callbacks. While I get that this can be
hard to grok given the magic of the syntax, it has nothing to do with the
difficulty of monads in math.

~~~
jimmyjazz14
do notation (in Haskell) is syntactic sugar, monads themselves are not.

------
cmars232
As one who has dabbled with Haskell a bit here and there, "programmable
semicolon" is the most apt metaphor I've seen.

Every time I have to break up a chain of method calls in Java with several
lines of ternary null checks, I think about the Maybe monad.

------
MichaelGG
I've found monads in programming languages to be a lot easier to understand
than the myriad "guides" that explain them in obtuse ways.

------
cageface
Sometimes it really amazes me just how far out of touch with the mainstream
people in the FP community can be. Any concept that the elite struggle with as
much as monads simply has no place in the working programmer's toolbox.
Haskell is a wonderful research language. It and its ilk will never be bread &
butter.

~~~
nopassrecover
The same could be said originally for generics and lambdas which have become
increasingly common elements of programming. Complex ideas can yield
powerfully simple and useful implementations.

~~~
forkandwait
I would say about one out fifty (2%) of bread and butter programmers can
actually figure out how to pass an anonymous function as a parameter to
another function. Granted, those 2% are probably a lot more important than the
other 48%, but I don't think lambdas are actually common...

Also, if one of those 2% have to write code understood by the other 48%, they
probably shouldn't use a ton of anonymous functions (or generics, whatever
they are).

~~~
kscaldef
Are you saying that you think only 2% of programmers are capable of
programming in Ruby? Blocks are pervasive in Ruby, and although technically
slightly different than anonymous functions, conceptually very similar.

(Also, you mean "the other 98%".)

~~~
chromatic
Perhaps the distinction between "can copy and paste existing syntax examples"
and "understand what the syntax does" is significant.

