[Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Andrew Coppin]

John Goerzen wrote:
>   Haskell
>   developers, stop letting the category theorists name
>   things. Please. I beg of you. 
>
> I'd like to echo that sentiment!
>
> He went on to add:
>
>   If you?re not a category theorists, and you're learning (or thinking
>   of learning) Haskell, don't get scared off by names like "monoid" or
>   "functor". And ignore anyone who starts their explanation with
>   references to category theory- you don't need to know category
>   theory, and I don't think it helps.
>
> I'd echo that one too.
>   

I am constantly shocked and saddened at the Haskell community's attitude 
here. It seems to boil down to "Why should we make it easier to learn 
Haskell? If people aren't prepaired to learn abstract algebra, category 
theory, predicate logic and type system theory, why should we bother to 
help them?" So much for the famously helpful Haskell community.

I am seriously beginning to wonder if the people using Haskell actually 
realise what regular programmers do and don't know about. (You may 
recall my recent straw poll where 80% of the programmer nerds I asked 
had no clue what a "coroutine" is or what "existential quantification" 
means.)

Notice that "monoid" sounds almost *exactly* like "monad". And yet, what 
you use them for is wildly unrelated. In a similar vein, who here can 
tell me off the top of their head what the difference between an 
epimorphism and a hylomorphism is? I've got a brick-thick group theory 
book sat right next to me and *I* can't even remember! Best of all, if 
Joe Programmer makes any attempt to look these terms up, the information 
they get will be almost completely useless for the purposes of writing 
code or reading somebody else's.

I was especially amused by the assertion that "existential 
quantification" is a more precise term than "type variable hiding". (The 
former doesn't even tell you that the feature in question is related to 
the type system! Even the few people in my poll who knew of the term 
couldn't figure out how it might be related to Haskell. And one guy 
argued that "forall" should denote universal rather than existential 
quantification...) The sad thing is, it's not actually complicated. The 
documentation just makes it seem like it is! :-(

Databases are based on the relational algebra. But that doesn't seem to 
stop them from coming up with names for things that normal humans can 
understand without first taking a course in relational algebra. (Does 
the Oracle user guide state that "a relation is simply a subset of the 
extended Cartesian product of the respective domains of its attributes"? 
No, I don't *think* so! It says "Oracle manages tables which are made up 
of rows..." Technically less precise, but vastly easier to comprehend.) 
Why can't we do the same?

If we *must* insist on using the most obscure possible name for 
everything, can we at least write some documentation that doesn't 
require a PhD to comprehend?? (Anybody who attempts to argue that 
"monoid" is not actually an obscure term has clearly lost contact with 
the real world.)

As somebody else said, it basically comes down to this: Who the hell is 
Haskell actually "for"? If it's seriously intended to be used by 
programmers, things need to change. And if things aren't going to 
change, then let's all stop pretending that Haskell actually cares about 
real programmers.

Sorry if this sounds like just another clueless rant, but I'm really 
getting frustrated about all this. Nobody seems to think there's 
actually a problem here, despite the incontravertible fact that there is...



PS. As a small aside... Is the Monoid class actually used *anywhere* in 
all of Haskell? Surely saying that something is a monoid is so vague as 
to be unhelpful. "The most you can say about almost everything is 
practically nothing" and all that. All it means is that the type in 
question has a function that happens to take 2 arguments, and this 
function happens to have an identity value. How is this information 
useful? Surely what you'd want to know is what that function *does*?! 
And since a given type can only be a Monoid instance in one way, 
wouldn't passing the function and its identity in as parameters be 
simpler anyway? The integers form at least two different monoids AFAIK...