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...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
