On Thu, Jan 15, 2009 at 1:29 PM, Andrew Coppin
But you really *should not* need to do an undergraduate course in mathematical theory just to work out how to concat two lists. That's absurd. Some kind of balance needs to be found.
Balance is good, but it's hard to find a balance when people exaggerate so much. Firstly: You don't need monoids to concat two lists. You need monoids when you want to abstract the operation of concatting two lists so that the same code can be reused in other ways. A good example is the writer monad. The author of that monad could have made it work just with strings. But one of the coollest things about Haskell is the way it's so amenable to micro-refactoring. By realising there's a bunch of other things the Writer monad can do using *exactly the same implementation* you get reusability. If you don't want this kind of reusability you may be better off with C or Fortran. Secondly: you don't need an "undergraduate course." to understand monoids. A monoid is just a collection of things with an operation allowing you to combine two things to get another one. And an element that acts like 'nothing' so that when you combine it with other elements it leaves them unchanged (and an additional simple condition). This would be the first 30 seconds of a course on monoids that presupposes nothing more than a naive idea of what a set is. The only thing that's difficult about monoids is that it's a new word. There's little 'theory' involved. Your talk of undergraduate courses to concat two lists isn't grounded in any kind of reality, muddies the waters, and probably scares people away from Haskell by giving the impression that it's much harder than it is. -- Dan