4 ms·

Then try Monad -> Sequenced Functor -> Mapable Category -> ... I don't know, I don't use it much (not that it doesn't have a nice understandable al

by axman6 13y ago

Then try Monad -> Sequenced Functor -> Mapable Category -> ... I don't know, I don't use it much (not that it doesn't have a nice understandable alternative name, I just don't know it) Monad and Functor are really quite simple classes to understand, and Tony Morris' 20 intermediate exercises listed in the article helped me greatly when trying to understand the concepts. I've been a haskell programmer for 6 years, and feel I know about zero cetrgory theory. It's never seemed to hurt me (except when Edward Kmett pipes up in IRC and I don't understand a word after that =)

joe_the_user 13y ago
Yes, that works much better. But that isn't what the article said. I'm a c++ programmer who consumes the occasional Haskell articles on hn. By dint of complaining and hearing sensible explanations, I feel like I'm "getting it". But I don't think that takes from the notable phenomena of opaquely ridiculous explanations of Haskell ideas that seem to pop-up regularly. http://www.chrisstucchio.com/blog/2013/write_some_fucking_code.html http://www.chrisstucchio.com/blog/2013/write_some_fucking_co... Edit: I kind of feel like there's this phenomena where someone is "real math guy" and so they'd rather people to wholly ignore the structures the language is built on, call functors Poptarts etc, rather than giving a simplified explanation which would leave them open to other real math guys complaining the explanation wasn't exact/cool/powerful enough.
ekidd 13y ago
For Monad, try "Flattenable". A monad is any type which: 1. Supports map. 2. Can be instantiated given a single value. 3. Can be "flattened" when nested two layers deep. For example, an ordered list is a monad, because: 1. You can map a function over a list. 2. Given a value x, you can construct the list [x]. 3. Given a list like [[1,3], [2], [], [4,5]], you can flatten it to be [1,3,2,4,5]. There are a couple of other technical constraints, mostly related to what happens when you (for example) take a list, stick into another list using rule (2), and flatten it using rule (3), in which case you're supposed to get back the original list. That sort of thing. Monads are useful, and they appear everywhere—quite a lot of generic types support "map" and "flatten". Haskell obscures this simple structure in two unfortunate ways: (a) the first monad that everybody sees is IO, which is a freakish outlier, and (b) Haskell uses an equivalent formation of monads based on a function "bind", which is essentially a map (to a doubly nested type) followed by a flatten. Another way to look at monads is as "generalized list comprehensions" where "list" can be replaced with hundreds of different clever things. It's a clever little pattern that turns up everywhere, and when it does turn up, it tends to be a sweet spot in the design space. A good recent example would be the Promises/A+ spec for JavaScript, which is basically Haskell's Error monad.
- aninhumer 13y ago
  I think the fact that two people suggesting this idea chose two completely different names to replace "Monad" demonstrate pretty well why trying to use an "intuitive" name is a bad idea. I can just about get behind "Mappable" for Functor, but there simply isn't a unifying notion that explains what a Monad is in one word. Some Monads are better described by their join, and others are better described by their bind. You call IO a "freakish outlier", but Reader, Writer and State all follow a similar notion of sequence.
  - joe_the_user 13y ago
    I think the fact that two people suggesting this idea chose two completely different names to replace "Monad" demonstrate pretty well why trying to use an "intuitive" name is a bad idea. Uh so, Because when you have a complex idea which can be approached multiple ways, the best way to help people approach it is ... no way at all, no helping hands or training wheels. See my other complaints about "we don't want to let you be any bit OK until you have it all".
    - aninhumer 13y ago
      I'm not saying we can't use these words to help people understand, just that we shouldn't rename core elements of the language just for the benefit of beginners. Especially if the new names don't fit with half of their common use cases. Learning a new word is not what makes Monads hard.

by axman6 13y ago

joe_the_user 13y ago

Yes, that works much better. But that isn't what the article said. I'm a c++ programmer who consumes the occasional Haskell articles on hn. By dint of complaining and hearing sensible explanations, I feel like I'm "getting it". But I don't think that takes from the notable phenomena of opaquely ridiculous explanations of Haskell ideas that seem to pop-up regularly. http://www.chrisstucchio.com/blog/2013/write_some_fucking_code.html http://www.chrisstucchio.com/blog/2013/write_some_fucking_co... Edit: I kind of feel like there's this phenomena where someone is "real math guy" and so they'd rather people to wholly ignore the structures the language is built on, call functors Poptarts etc, rather than giving a simplified explanation which would leave them open to other real math guys complaining the explanation wasn't exact/cool/powerful enough.

ekidd 13y ago

For Monad, try "Flattenable". A monad is any type which: 1. Supports map. 2. Can be instantiated given a single value. 3. Can be "flattened" when nested two layers deep. For example, an ordered list is a monad, because: 1. You can map a function over a list. 2. Given a value x, you can construct the list [x]. 3. Given a list like [[1,3], [2], [], [4,5]], you can flatten it to be [1,3,2,4,5]. There are a couple of other technical constraints, mostly related to what happens when you (for example) take a list, stick into another list using rule (2), and flatten it using rule (3), in which case you're supposed to get back the original list. That sort of thing. Monads are useful, and they appear everywhere—quite a lot of generic types support "map" and "flatten". Haskell obscures this simple structure in two unfortunate ways: (a) the first monad that everybody sees is IO, which is a freakish outlier, and (b) Haskell uses an equivalent formation of monads based on a function "bind", which is essentially a map (to a doubly nested type) followed by a flatten. Another way to look at monads is as "generalized list comprehensions" where "list" can be replaced with hundreds of different clever things. It's a clever little pattern that turns up everywhere, and when it does turn up, it tends to be a sweet spot in the design space. A good recent example would be the Promises/A+ spec for JavaScript, which is basically Haskell's Error monad.

aninhumer 13y ago
I think the fact that two people suggesting this idea chose two completely different names to replace "Monad" demonstrate pretty well why trying to use an "intuitive" name is a bad idea. I can just about get behind "Mappable" for Functor, but there simply isn't a unifying notion that explains what a Monad is in one word. Some Monads are better described by their join, and others are better described by their bind. You call IO a "freakish outlier", but Reader, Writer and State all follow a similar notion of sequence.
- joe_the_user 13y ago
  I think the fact that two people suggesting this idea chose two completely different names to replace "Monad" demonstrate pretty well why trying to use an "intuitive" name is a bad idea. Uh so, Because when you have a complex idea which can be approached multiple ways, the best way to help people approach it is ... no way at all, no helping hands or training wheels. See my other complaints about "we don't want to let you be any bit OK until you have it all".
  - aninhumer 13y ago
    I'm not saying we can't use these words to help people understand, just that we shouldn't rename core elements of the language just for the benefit of beginners. Especially if the new names don't fit with half of their common use cases. Learning a new word is not what makes Monads hard.