Perhaps as a math/CS major I'm a bit biased here, but as a haskell
neophyte, I think my opinion is at least somewhat relevant...
The immediate problem is certainly documentation. No one would groan
more than once after hearing a term from abstract math if there was
sufficient Haskell-oriented language. I can say that a monad is an
endo-functor (in this case on Hask) which is the composition of two
natural transformations; the clever parrot I am, I can even understand
most of this... but that doesn't mean anything to me in a Haskell
context; until a new Haskell programmer can find a Hasktionary with
relevant terms in a Haskell context, everything is meaningless-- even
though I can understand (i.e. apply meaning to) the definition of a
monad on Hask, I can't apply the sort of meaning required to program
with a monad without either figuring it out through experience, or
seeing it shown to me in a programmer-relevant way (Or rather, both need
to happen.)
On the other hand, I really, really like getting behind things and
understanding the theory. In C, well, C is the theory-- if I want to go
deeper, I need to learn as much as I can about the way a computer
actually, physically works (why, why, then, even have higher level
languages?) or I need to take a history lesson so I can figure out the
math that helped out... With Haskell, the theory is right there, staring
at me. If the documentation were better, I wouldn't *need* to learn it,
but if my curiosity is piqued, it's right there. Naming monoid
"appendable" kills that-- by trying to make things "warm and fuzzy",
you've weakened one of my strongest motivators for programming
(especially in Haskell), namely how much of a direct application of cool
math it is. I know I'm not the only one.
As far as I know, one of the draws of Haskell is the inherent
mathematical nature of it-- in how many other languages do people write
proofs of correctness because they don't want to write test-cases? The
kind of people who are going to be drawn to a language which allows
[(x,y)| x<-somelist, y<-someotherlist] are overall, a mathy set of
people, and trying to make our terms fuzzy isn't going to change that.
So why not embrace it?
This leads to another point: monoids are probably called monoids for the
same reason monads are monads: they came directly out of higher math.
Someone did sit down trying to name this cool new Haskell idea he had
and then say, "Oh, of course, it's just [insert "obscure" math word
that's used in Haskell]! I'll keep that name." He sat down, and said,
"Oh! Wait if I use [insert "obscure" math word that's used in Haskell]
this problem is simpler." It's named for what it is: a monoid, a monad,
a functor, existential quantification.
But there's a deeper problem here, one that can't be resolved inside the
Haskell community. The problem is that the "Math?! Scary! Gross!"
attitude that's so pervasive in our society is hardly less pervasive in
the computer subculture. I shouldn't be more able to discuss abstract
math with a conservatory dropout theater student than with someone who
plans, for a living, to put well-formed formulae onto a finite state
machine. I am.
I don't expect the average programmer to be able to give me a
well-ordering of the reals (with choice, of course), or to prove that
category C satisfying property P must also satisfy property Q; but for
God's sake, they better have a good intuition for basic set theory,
basic graph theory, and most importantly mathematical abstraction. What
is "good coding style" if not making the exact same types of
abstractions that mathematicians make? Again, I don't expect a CS major
to write a good proof, to explain rings to a 13 year old, or actually
"do" real math; but I expect one to be able to read "In abstract
algebra, a branch of mathematics, a monoid is an algebraic structure
with a single, associative binary operation and an identity element. "
and be able to get a basic intuitive idea for what a monad is; with some
thought of course. I would go so far as to say that a programmer should
be able to intuitively understand "a system of objects and associative
arrows", even if they can't "do math" with that... Programmers shouldn't
be allowed to get away with the absolute ignorance of math that at least
75% of the CS majors at my school pass with.
This doesn't mean there isn't a serious problem with Haskell
documentation; it also doesn't mean that everyone should have a minor in
math to be a programmer, but isn't an introductory course in discrete
math required for most CS programs? Then why are programmers so afraid
of basic mathematical definitions? And why do so many wear their
ignorance and fear of math as a badge of honor?
Sorry that this came out as a bit of a rant, but I spend enough time
trying to convince people that math isn't horrid and disgusting...
Cory Knapp
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
