Andrew Coppin wrote:
Abstraction is a great thing to have. I'd just prefer it to not look so intimidating;
What makes it look intimidating? If the answer is "it looks intimidating because the documentation consists of nothing more than a mathematical term, without a definition, and a reference to a paper", then I agree with you, and it seems so does most everyone else. But if the intimidation factor is coming from preconceptions like "it's mathy, therefore it's scary"; or "it's an unfamiliar term, therefore it's scary", then I think that's something that the reader needs to work on, not the designers and documenters of Haskell. Computer programming is full of terms that need to be learned, and if anything terms like "monoid" are fantastically useful because they're so precisely defined, and are part of a larger well-defined universe. I would have thought that any "true programmer" (like a true Scotsman) could appreciate the separation of concerns and factoring that's gone into abstract algebra. The idea that it's not relevant to programming (an implication that was made earlier) misses a bigger picture. How could a collection of very general structures associated with general operations *not* be relevant to programming? Given that mathematicians have spent centuries honing these useful structures, and given that plenty of applications for them in programming have been identified, it would virtually be a crime not to use them where they make sense. (A crime against... humanity? I look forward to the trials at The Hague of errant programming language and library designers.)
the majority of these abstractions aren't actually "complicated" in any way, once you learn what they are...
Which underscores my question - what's the source of the intimidation, then?
If you're going to implement an abstraction for monoids, you might as well call it "monoid". On that I agree.
Excellent.
I still think "appendable" (where it really *is* used only for appendable collections) is a more useful abstraction to have, since it's more specific. Generalising things is nice, but if you generalise things too far you end up with something too vague to be of practical use.
That's only one side of the story. Quite a few examples of monoid use has been given in this thread. How many of them are actually uses of Appendable, I wonder? There's an equal and opposite risk of under-generalizing here: if you design something to take an Appendable argument, and if Appendable precludes other kinds of "non-appendable" monoids, you may be precluding certain argument types that would otherwise be perfectly reasonable, and building in restrictions to your code for no good reason - restrictions that don't relate to the actual requirements of the code. Of course, if you're just saying you want Appendable as an alias for Monoid, that's reasonable (I mentioned that possibility in another message), but a similar effect might be achieved by documentation that points out that appendability is one application for monoids. A more suitable "friendly" synonym for "monoid" might be "combinable", which can more easily be defended: a binary operation combines its arguments by definition, since it turns two arguments into one result. But again, it would make more sense to observe in the documentation that monoids are combinable things, for various reasons that others have already addressed. I like the reasons that Manuel Chakravarty gave - in part, "the language and the community favours drilling down to the core of a problem and exposing its essence in the bright light of mathematical precision". If anyone finds that scary, my advice to them is to wear sunglasses until they get used to it. In practice, what that means is don't fuss over the fact that there's a lot of unfamiliar knowledge that seems important -- yes, it is important, but you can use Haskell quite well without knowing it all. I speak from experience, since I'm not a mathematician, let alone a category theorist. Anton