[Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Anton van Straaten]

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