Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monads explained by Eric Lippert

ericlippert.com

Post reply on HN
Print view View original

11–20 of 58 posts

Re: Monads explained by Eric Lippert

#11

Post by raverbashing »

kryptiskt wrote: post #5
gngeal wrote: post #4

Earlier quoted context omitted.

"For example, math has some very high-level/generic explanations, and curiously, I find them more understandable." That's because math always "goes straight to the point". There's nothing but the raw substance in it.

When I read math, I really like some motivating examples before digging into the definitions and theorems. For me, concrete examples makes it way easier to grasp abstract concepts.

Oh, I agree, sometimes it's too generic =)

Especially if you don't know the names used in the description.

The problem is that I can't stand explanations that would go like this if it was explaining Math:

"So, we have a natural number, that is 2, 7, or 34232345 and by the way they're all integer numbers as well, also they are rational numbers as well, oh and there's equation you can do with them, but ok, so you can sum those numbers, etc"

I'd rather go with

"This turns the natural numbers (N, +) into a commutative monoid with identity element 0,"

Re: Monads explained by Eric Lippert

#14

Post by arianvanp »

Monads should be a familiar concept for the seasoned C# programmer. LINQ's 'from in' syntax and the haskell monad 'do' syntax are almost the same!

Heck, the type signature of SelectMany and (>>=) are even the same!

    (>>=) ::  m a -> (a -> m b) -> m b
and

    public static IEnumerable SelectMany(
    	this IEnumerable source,
    	Func> selector
    )

    m = IEnumerable
    b = TResult
    a = TSource

    =>   m SelectMany(this m source, Func> selector)
The type signatures are _EXACTLY_ the same. This isn't a coincidence. LINQ is actually a monad :)

So I think taking this approach to explain the Monad voodoo to a C# programmer is the way to go. He actually uses them already :)

Re: Monads explained by Eric Lippert

#15

Post by interconnector »

ufo wrote: post #2

Note that this is a series of posts. The first post that is being linked to doesn't have much IMO. http://ericlippert.com/2013/02/21/monads-part-one/ http://ericlippert.com/2013/02/25/monads-part-two/ http://ericlippert.com/2013/02/28/monads-part-three/ I wasn't clear for me but in the last post he mentioned that there would be more posts to come.

There's a part four as well: http://ericlippert.com/2013/03/04/monads-part-four/

Re: Monads explained by Eric Lippert

#16

Post by papsosouid »

raverbashing wrote: post #3

Do you know what I miss about these explanations? Technical people can't go straight to the point. They go around, around, around, going into corners, etc (not only on explanations, mind you) For example, math has some very high-level/generic explanations, and curiously, I find them more understandable. So, I've given up on understanding Monads (or at least Haskell ones), I'll probably understand them when I come up…

I agree, monad explanations that use analogies are bad. There is no need for analogy, it is a simple concept, and is easiest to learn from an explanation of the actual concept, not semi-accurate sometimesish analogies.

I think this is the best monad introduction I've seen: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad... It shows you why monads are a thing, what kinds of problems they can be used to solve, and then you see the overall pattern of how those different problems share the same underlying pattern (they are monads).

Re: Monads explained by Eric Lippert

#17

Post by daniel-levin »

Monads are actually a very simple concept. They're really hard to understand at first because of how much knowledge is prerequisite. I found that by teaching myself Haskell incrementally, in small steps, I was able to understand monads just as easily as anything else. For me, it was simply resolving the following dependency graph:

Algebraic data types -> type classes -> functors -> applicative functors -> monoids -> monads.

I need to emphasise that understanding of each stage is predicated on understanding of the previous stage. Trying to learn monads without understanding these other concepts is like trying to learn Maxwell's equations without an understanding of calculus and physics.

Lippert states: "Plenty of developers have used the monad pattern entirely by accident, not realizing that they're re-inventing something that already has a name.". This is completely true. For instance, watch this video on refactoring by Ben Orenstein [1]. He 'destroy[s] conditionals with a NullObject'. This is exactly how the maybe monad works.

[1] http://www.youtube.com/watch?v=DC-pQPq0acs

Re: Monads explained by Eric Lippert

#19

Post by Peaker »

DannoHung wrote: post #7

Monads are complicated because the word "monad" bears too much weight in any discussion about them. 1) There is a category theoretical concept of a monad. This is largely irrelevant in a practical explanation of monads since Monads are usually talked about in terms of another category theoretical concept called the Kleisli Category or Kleisli Triple. However, if someone starts talking about "monad laws", they're prob…

Minor nitpicks:

"Monadic types" and "Monadic values" would be better for 4 and 5, because "Monad types" are the type constructors (which are also sometimes named types). And "monad values" is not a term I've ever heard used.

Also, values have-type, they're not instance-of. So it would be slightly more accurate to say monadic values are values of a monadic type, whose type constructor is an instance of the Monad type-class.

I agree better and more accurate use of accepted terminology for all these concepts could be useful.

As for the namespacing issue in the examples, it might be confusing for a complete beginner, but one of the first things you learn in Haskell (ideally before Monads) is how scoping works.

Post reply on HN