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

41–50 of 58 posts

Re: Monads explained by Eric Lippert

#41

Post by qznc »

Scriptor wrote: post #22
qznc wrote: post #18

Why do you need to understand monads? Nobody explains groups to people using integers, either.

You've never been curious about something you don't know about, but don't immediately need?

In general the Haskell community seems way too obsessed about monads. I just checked the "official" tutorials [0]. I was happy to see they all introduce IO without talking about monads. However, the linked wiki page has a whole section about monads. In contrast, there nothing about concurrency or transactional memory, despite that fact that this is one of the strong parts of Haskell.

http://www.haskell.org/haskellwiki/Tutorials

Re: Monads explained by Eric Lippert

#42

Post by runT1ME »

arianvanp wrote: post #14

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 > select…

It goes beyond that . LINQ isn't a monad, it's monadic syntax for any monad. It just so happens that the one everyone uses is IEnumerable.

Here, I wrote the Reader monad for IoC to show it could be done:

https://gist.github.com/vmarquez/4640678

Re: Monads explained by Eric Lippert

#43

Post by papsosouid »

qznc wrote: post #41
Scriptor wrote: post #22

Earlier quoted context omitted.

You've never been curious about something you don't know about, but don't immediately need?

In general the Haskell community seems way too obsessed about monads. I just checked the "official" tutorials [0]. I was happy to see they all introduce IO without talking about monads. However, the linked wiki page has a whole section about monads. In contrast, there nothing about concurrency or transactional memory, despite that fact that this is one of the strong parts of Haskell. http://www.haskell.org/haskellwik…

>In general the Haskell community seems way too obsessed about monads

You need to understand monads to do anything beyond trivial exercises. It is something that virtually every single person coming to haskell from another language is unfamiliar with. I don't see how a focus on such a fundamental aspect of the language is a bad thing.

Re: Monads explained by Eric Lippert

#44

Post by pekk »

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…

This is beautifully explained.

The obligation to know specialized theoretical concepts like the Kleisli Category might indicate that all this is not much of an ergonomic help for reasoning about code. Making things more conceptually complicated and require more background information is probably not the best way to amplify a person's ability to understand the implications of the code they see in front of them or have just produced.

Re: Monads explained by Eric Lippert

#45

Post by DanWaterworth »

paulrademacher wrote: post #39
DanWaterworth wrote: post #38

Earlier quoted context omitted.

I understand monads and use them everyday, but I've never written an article about them. I did once try to explain to someone what a monad is... that could be the reason I've never tried.

You should write an article!

I'll start with the continuation monad, explaining that via the Curry-Howard correspondence it is related to a double negative. I'll go on to show that the continuation monad is more general than any other monad by showing how to implement some common ones (state, list, IO, coroutines) using it. I'll finish with a half-baked analogy.

Re: Monads explained by Eric Lippert

#46

Post by pekk »

serpi wrote: post #6

The monad is the clitoris of programming.

One of these things is routinely found by most humans, and the finding can be taught to an idiot in one or two sentences.

If you are going to make an improper analogy for monads, it should probably be the prostate or the g-spot.

Re: Monads explained by Eric Lippert

#47

Post by DannoHung »

pekk wrote: post #44
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…

This is beautifully explained. The obligation to know specialized theoretical concepts like the Kleisli Category might indicate that all this is not much of an ergonomic help for reasoning about code. Making things more conceptually complicated and require more background information is probably not the best way to amplify a person's ability to understand the implications of the code they see in front of them or have…

You don't really need to know anything about the monad laws until you're actually ready to write your own. And you probably aren't going to need to write your own Monads until you're already pretty familiar with how other instances work.

Some people like to explain stuff from the theoretical perspective first. I honestly don't think the theoretical aspect is all that confusing, but it's unfortunately besides the point unless you're writing an article on how and why individual Monads adhere to those laws.

Re: Monads explained by Eric Lippert

#48

Post by unconed »

gngeal wrote: post #4
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…

"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.

I find the best analogy is with optimized code. It's not like you're deliberately obfuscating it, but still, in trying to write it as succinctly as possible, some of the information has gotten lost.

Re: Monads explained by Eric Lippert

#49

Post by krallja »

chadzawistowski wrote: post #26
arianvanp wrote: post #14

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 > select…

Further proof for my personal conviction that C# is a very interesting, progressive language which masquerades as a Java clone. I once copied the style of a maybe monad using LINQ - the WinRT apis lack a "FileExists?" method, so I used LINQ to search a directory's contents for a filename. An IEnumerable of size of zero represented None, and size one represented Some. Unfortunately, a simple try/catch around an attemp…

LINQ has an .Empty() extension method, and you should use that instead of .Count()==0 when determining if an expression is empty.

Re: Monads explained by Eric Lippert

#50

Post by KirinDave »

I tried to like this series. I really did. And it starts out so strong...

The thing is, you can't escape talking about the specific implementation details of monads while talking about monads, otherwise you lose the plot of what we're doing and why. Saying, "Monads are just code patterns" is like saying, "All matter in the universe is just energy patterns," strictly correct but unhelpful for any true insight.

Its okay to skip the monad laws at first, but what's not okay is to talk about why there are so many Monads or what actually constitutes a monad. The best writing I've ever seen on this subject is from Learn You A Haskell for Great Good, where they walk you through a piece of code and then show how using a monad makes it cleaner and less tedious.

By the end of those 2 chapters from LYAH, you end up with the sense that monads are obvious and natural. And they are once you understand the sorts of problems they solve. I wish we had more of that.

Post reply on HN