[Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Anton van Straaten
anton at appsolutions.com
Fri Jan 16 17:02:00 EST 2009
Andrew Coppin wrote:
> Abstraction is a great thing to have. I'd just prefer it to not look so
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.
> 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
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
More information about the Haskell-Cafe