[Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Andrew Coppin]

Ketil Malde wrote:
> The problem is that many Haskell constructs are so abstract and so
> general that precise names will be obscure to anybody with no
> background in logic (existential quantification), algebra (monoid) or
> category theory (monad).  This level of abstraction is a great
> benefit, since it allows reuse of code and concepts, but the problem
> is internalizing the abstraction and learning to recognize how it
> works for different concrete data types.
>   

Abstraction is a great thing to have. I'd just prefer it to not look so 
intimidating; the majority of these abstractions aren't actually 
"complicated" in any way, once you learn what they are...

> As pointed out numerouos times, calling Monoids "Appendable" would be
> wildly misleading.  But I think the real problem here is learning and
> understandig very abstract concepts, not the names.
>   

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.

> I agree (with everybody) that documentation is lacking.

If there is one single thing to come out of this giant flamewar, I hope 
it's better documentation. (I'll even lend a hand myself if I can figure 
out how...) Clearer documentation can't possibly be a bad thing!

>> (Anybody who attempts to argue that "monoid" is not actually an
>> obscure term has clearly lost contact with the real world.)
>>     
>
> Anybody who calls Monoids "Appendable" has clearly lost contact with
> their programming language :-)
>   

Calling something "appendable" if it really is a general monoid would be 
slightly silly, yes.