[Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Cory Knapp]

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