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

[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe