10 ms·

Ahahah, that might be true :) Although because those concepts comes from category theory, i.e. https://en.wikipedia.org/wiki/Functor https://en.wikipedia.org/wi

by mokagio 11y ago

Ahahah, that might be true :) Although because those concepts comes from category theory, i.e. https://en.wikipedia.org/wiki/Functor https://en.wikipedia.org/wiki/Functor and there's more to it than just "it defines" map, keeping the "academic" name seems fair enough.

corysama 11y ago
Are there any nice, one-step-at-a-time introductions to Haskell that stick to lowly, commonplace English rather than insisting that "just a monoid in the category of endofunctors" is universally preferable because technically it technically is technically more technically correct?
- chongli 11y ago
  I haven't read it but you might want to check out coolsunglasses'[0] book, Haskell Programming from first principles[1]. He wrote it specifically for people who have no background in this stuff. [0] https://news.ycombinator.com/user?id=coolsunglasses https://news.ycombinator.com/user?id=coolsunglasses [1] http://haskellbook.com/ http://haskellbook.com/
- ucarion 11y ago
  To add to chongli's suggestion, I learned Haskell (and had a great time doing it) from "Learn You a Haskell": http://learnyouahaskell.com/ http://learnyouahaskell.com/
- wetmore 11y ago
  Nobody insists "monoid in the category of endofunctors" is universally preferable. It's a joke. What you'll usually see people insist is to describe monads by their operations, rather than through metaphor. That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g) For monads in Haskell, this is the technically correct definition. That said, most people will tell you the best way to understand monads is to look at a few basic monad instance implementations (Maybe, Either a) and program with them, slowly learning new instances.
  - dllthomas 11y ago
    Cleaning up the parent's formatting as I think it's too late for them to edit. Content is unchanged: That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)
- merijnv 11y ago
  To be fair, I don't know a single person that explains things using > "just a monoid in the category of endofunctors" In fact, even among people who DO know the category theory necessary to understand this expression it's considered a very obtuse and useless explanation. Especially in the context of Haskell. As for good readable introductions, I consider Wadler's paper "Monads for Functional Programming" to actually be a pretty good introduction. Another good intro is "You Could Have Invented Monads! (And Maybe You Already Have.)" http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
jameshart 11y ago
The problem is that the category-theory view of functors and monads and monoids completely dominates the literature. Imagine if, when you first started programming, and you wanted to do something with numbers, and you found out that in your programming language, the way you did that was to use something they called "Integers" (I know, right? ridiculous). So you google "Integers" and you find https://en.wikipedia.org/wiki/Integer https://en.wikipedia.org/wiki/Integer, which helpfully tells you "In elementary school teaching, integers are often intuitively defined as the disjoint union of the (positive) natural numbers, the singleton set whose only element is zero, and the negations of natural numbers."[1] And you get the impression that to add a couple of numbers together you're actually going to have to understand cardinality and group theory and so on. That's kind of where we are with monads, with the insistence on the academic language. Though it does suggest that I could have fun by persuading beginning programmers that to really grok text processing they need to start off with a thorough grounding in string theory. [1] I checked with my son, who goes to elementary school. I'm not sure he even knows what a disjoint union is. I'll have to have words with the teacher.
- LimpWristed 11y ago
  You're over-exaggerating :) From the wiki link, the very first definition works just fine. In fact, I don't see anything about unions, disjointedness in there. Certainly, no group theory. You don't need to know how to construct, count(cardinality) or know the properties of integers(number/group theory) to know what they are for the purposes of programming. No, there's no cabal making everything more difficult than it needs to be ;D I think wiki always gets unfairly maligned for this sort of thing.
- TillE 11y ago
  I'd forgotten how spectacularly academic Wikipedia's math articles are. It actually seems a little better than it used to be, but for example good luck learning what the hell a quaternion is by reading the Wikipedia article, even if you have sufficient background to understand and use them in practice. The German article is much better.
  - Ivanov 11y ago

by mokagio 11y ago

corysama 11y ago

Are there any nice, one-step-at-a-time introductions to Haskell that stick to lowly, commonplace English rather than insisting that "just a monoid in the category of endofunctors" is universally preferable because technically it technically is technically more technically correct?

chongli 11y ago
I haven't read it but you might want to check out coolsunglasses'[0] book, Haskell Programming from first principles[1]. He wrote it specifically for people who have no background in this stuff. [0] https://news.ycombinator.com/user?id=coolsunglasses https://news.ycombinator.com/user?id=coolsunglasses [1] http://haskellbook.com/ http://haskellbook.com/
ucarion 11y ago
To add to chongli's suggestion, I learned Haskell (and had a great time doing it) from "Learn You a Haskell": http://learnyouahaskell.com/ http://learnyouahaskell.com/
wetmore 11y ago
Nobody insists "monoid in the category of endofunctors" is universally preferable. It's a joke. What you'll usually see people insist is to describe monads by their operations, rather than through metaphor. That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g) For monads in Haskell, this is the technically correct definition. That said, most people will tell you the best way to understand monads is to look at a few basic monad instance implementations (Maybe, Either a) and program with them, slowly learning new instances.
- dllthomas 11y ago
  Cleaning up the parent's formatting as I think it's too late for them to edit. Content is unchanged: That is, a monad is a type parametrized by some other type, with the following two functions: 1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b such that three laws hold: a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)
merijnv 11y ago
To be fair, I don't know a single person that explains things using > "just a monoid in the category of endofunctors" In fact, even among people who DO know the category theory necessary to understand this expression it's considered a very obtuse and useless explanation. Especially in the context of Haskell. As for good readable introductions, I consider Wadler's paper "Monads for Functional Programming" to actually be a pretty good introduction. Another good intro is "You Could Have Invented Monads! (And Maybe You Already Have.)" http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

jameshart 11y ago

The problem is that the category-theory view of functors and monads and monoids completely dominates the literature. Imagine if, when you first started programming, and you wanted to do something with numbers, and you found out that in your programming language, the way you did that was to use something they called "Integers" (I know, right? ridiculous). So you google "Integers" and you find https://en.wikipedia.org/wiki/Integer https://en.wikipedia.org/wiki/Integer, which helpfully tells you "In elementary school teaching, integers are often intuitively defined as the disjoint union of the (positive) natural numbers, the singleton set whose only element is zero, and the negations of natural numbers."[1] And you get the impression that to add a couple of numbers together you're actually going to have to understand cardinality and group theory and so on. That's kind of where we are with monads, with the insistence on the academic language. Though it does suggest that I could have fun by persuading beginning programmers that to really grok text processing they need to start off with a thorough grounding in string theory. [1] I checked with my son, who goes to elementary school. I'm not sure he even knows what a disjoint union is. I'll have to have words with the teacher.

LimpWristed 11y ago
You're over-exaggerating :) From the wiki link, the very first definition works just fine. In fact, I don't see anything about unions, disjointedness in there. Certainly, no group theory. You don't need to know how to construct, count(cardinality) or know the properties of integers(number/group theory) to know what they are for the purposes of programming. No, there's no cabal making everything more difficult than it needs to be ;D I think wiki always gets unfairly maligned for this sort of thing.
TillE 11y ago
I'd forgotten how spectacularly academic Wikipedia's math articles are. It actually seems a little better than it used to be, but for example good luck learning what the hell a quaternion is by reading the Wikipedia article, even if you have sufficient background to understand and use them in practice. The German article is much better.
- Ivanov 11y ago