4 ms·

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

by qznc 14y ago

Scriptor 14y ago
You've never been curious about something you don't know about, but don't immediately need?
- mokus 14y ago
  Whether any particular tutorial is good or not, it's almost automatic that people (especially in the Haskell community) question whether we needed /yet another/, because there are already so many and most of them are not that great. IMO there's nothing wrong with more, but the fact that there are so many out there seems to perpetuate the incorrect belief that it's something you need to learn to actually use Haskell. I suspect that the GP was addressing this belief, not saying "nobody should bother learning this stuff".
- qznc 14y ago
  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 http://www.haskell.org/haskellwiki/Tutorials
  - papsosouid 14y ago
    >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.
mokus 14y ago
Agreed. Just a couple days ago I was having a discussion with someone about how Haskell's type system is able to quarantine effects (he's a long time C++ and Python user who wanted some help seeing how a type system could possibly do that). I managed to explain it without ever using the "M word". Instead, I explained that "functions" in Haskell are deterministic and that "procedures" have a different type from functions. From there it was pretty easy to add that there are also types that represent more-restricted kinds of procedures that only have access to a limited set of effects. If he ever decides to take the plunge and actually learn some Haskell, I'll connect the idea up to the Monad class as "the minimal interface common to all procedure types", with emphasis on the idea that it's just the minimal API necessary to make something like "do" notation work. That is really all a user needs to know about monads to get started with using them. Of course they need more if they'd like to implement their own, but by the time they're thinking along those lines most people will have already learned enough about them from osmosis since, as other people have remarked, it's not a hard concept - it just has a lot of prerequisites. Even then, though, most of what most users want is well enough served by a similarly shallow understanding of monad transformers (they add features to procedure types, etc.)

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

by qznc 14y ago

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

Scriptor 14y ago

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

mokus 14y ago
Whether any particular tutorial is good or not, it's almost automatic that people (especially in the Haskell community) question whether we needed /yet another/, because there are already so many and most of them are not that great. IMO there's nothing wrong with more, but the fact that there are so many out there seems to perpetuate the incorrect belief that it's something you need to learn to actually use Haskell. I suspect that the GP was addressing this belief, not saying "nobody should bother learning this stuff".
qznc 14y ago
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 http://www.haskell.org/haskellwiki/Tutorials
- papsosouid 14y ago
  >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.

mokus 14y ago

Agreed. Just a couple days ago I was having a discussion with someone about how Haskell's type system is able to quarantine effects (he's a long time C++ and Python user who wanted some help seeing how a type system could possibly do that). I managed to explain it without ever using the "M word". Instead, I explained that "functions" in Haskell are deterministic and that "procedures" have a different type from functions. From there it was pretty easy to add that there are also types that represent more-restricted kinds of procedures that only have access to a limited set of effects. If he ever decides to take the plunge and actually learn some Haskell, I'll connect the idea up to the Monad class as "the minimal interface common to all procedure types", with emphasis on the idea that it's just the minimal API necessary to make something like "do" notation work. That is really all a user needs to know about monads to get started with using them. Of course they need more if they'd like to implement their own, but by the time they're thinking along those lines most people will have already learned enough about them from osmosis since, as other people have remarked, it's not a hard concept - it just has a lot of prerequisites. Even then, though, most of what most users want is well enough served by a similarly shallow understanding of monad transformers (they add features to procedure types, etc.)