Hacker News Reader

Comment by brehaut | Hacker News Reader

I think this line of reasoning is why the C# team avoided the M word and introduced Linq for a range of things (sequence comprehensions, reactive programming etc) and is introducing the async syntax for more stuff in 5, even though they could all be implemented with the same more general model.

[edit] the M word is Monad

View on HN

I don't think there's anything inherently wrong with monads, it's just that nobody's figured out how to explain them yet :) This is somewhat compounded by the awful name and Haskell's less than practical character. My guess is that they'll turn up in a new language in a few years and everyone will wonder what they did without them.

I would agree. Also, the LINQ interface is the monadic interface with Bind / >>= renamed to SelectMany and return renamed to ToIdentity. You can use these directly or with syntax sugar, so i would suggest that they have already turned up in a language.

Anecdotally, I think microsoft flubbed the introduction by overemphasizing LINQ to SQL. This leaving a lot of developers I know thinking it was a one trick pony and never learning (for instance) LINQ over IEnumerable. Those who have since taken time to learn the non-SQL LINQ features do wonder how the lived without them.

Don't people argue that jQuery is DOM manipulation in monads? I sure ask what I did before jQuery :)

http://importantshock.wordpress.com/2009/01/18/jquery-is-a-m...

HN discussion: http://news.ycombinator.com/item?id=439116

People argue this, but not people who know what a monad is.

Care to clarify, or do you prefer just telling people they're wrong? The linked article is on the surface convincing, but I have never touched Haskell

I've spent more time explaining monads to HN than I have anything else. It comes up at least twice a day and I am tired of writing an explanation twice a day.

Go read the Typeclassopedia.

I think there's also the issue that they're a lot less convenient without built-in syntax (or macros). Haskell's do-notation makes >> look like a newline and >>= look like an assignment. Without this syntactic sugar, monadic code rarely looks like an elegant solution.

Without this syntactic sugar, monadic code rarely looks like an elegant solution.

I'm not sure this is widely agreed-upon. Here's what a program composed of pure functions looks like:

  quux = baz . bar . foo

This is a function of one argument that filters the input through foo, then bar, then baz. Just like UNIX pipes, but backwards.

Now let's try it with monads:

    quux = baz =<< bar =<< foo

Same thing; this is a function of one argument, one that passes that argument through foo, then bar, then baz.

>>= notation is quite elegant. do notation just makes functional programing look imperative.

A monad is simply a monoid in the category of Haskell endofunctors.

Reply on news.ycombinator.com