>> OK, now I actually *know* abstract algebra, and your statements still 
>> make no sense to me.
> 
> I suspect you just never really thought it thru. You know that a 
> compiler is just a bunch of rewrite rules, for example, right?

What do rewrite rules have to do with abstract algebra?

> Basically, everything a computer program does is mapping strings of bits 
> to abstract algebras. The I/O of a Turing machine is a mapping from 
> strings of whatever-symbols-can-be-on-the-tape to abstract algebras.

Still not making any sense...

>> You don't need to know the formal theory to understand how a simple 
>> loop works. Basic intuition will tell you that.
> 
> That's because the basics of predicate calculus are easy to learn. So 
> easy, you probably already knew them before you knew what it was called.

Well fair enough. But certain people seem to think that "if you haven't 
even bothered to do an undergraduate course in advanced mathematics, you 
shouldn't be allowed near a computer". Which just seems absurd to me...

>> The discussion seems to be gradually anealing towards the idea that 
>> it's not the *names* that are the problem, but the near-total lack of 
>> any semblance of documentation about them that doesn't assume you 
>> already hold a PhD in advanced mathematics.
> 
> In Haskell, yes, that could be the case.  For example, "mempty is the 
> identity of mappend" makes perfect sense, if you know what "is an 
> identity of" means.

...which *I* do, but your typical programmer has *no clue*.

This is really why the whole discussion started. Some blogger tried to 
switch from Python to Haskell, and was looking for a class called 
"appendable" or something. But no, it's called Monoid. Notice how this 
sounds almost exactly like Monad, yet does something wildly different. 
(Somebody was even kind enough to point out that a Monad *is* a Monoid. 
Yay, that's really going to help...)

>> Assuming you already know what a monoid is, this is quite transparent. 
>> If you've never heard of a monoid in your life, none of this makes the 
>> slightest semblance of sense. 
> 
> Sounds like someone needs to write a textbook about what the terms in 
> Haskell means.

My favourit is the documentation for the Writer monad. The documentation 
basically says "This module is inspired by [some random paper]". The 
paper in question is an essay on how to do polymorphic programming. It 
mentions a writer monad as a brief 6-line example program in passing, 
with no suggestion as to how you use it. Yay for documentation!

We need propper documentation here! The docs for existantial 
quantification are similarly vague. (But hey, it's a compiler manual, 
not a language tutorial... *sigh*)

>> However - and this is what makes me so angry - there is a strong 
>> element in the community who claim that Haskell should *only* be used 
>> by maths experts. I find that to be arrogant and elitist.
> 
> I suppose that is. I guess it depends on their goals. Telling someone 
> else what they should or should not use seems arrogant.

Yeah, what *are* Haskell's goals? An often-quoted one is "avoid success 
at all costs". They seem to be doing a good job!

Thing is, I really love Haskell. But I'm not a mathematician, so I can't 
understand lots of stuff. And the attitude seems to be "well if you're 
not clever like us, you should go back to Python" or similar.

>> The reasoning behind this seems to be "if you don't study category 
>> theory, you cannot write computer programs, so it's OK for Haskell to 
>> demand that everybody learns category theory before using it". This is 
>> of course easily falsifiable.
> 
> Haskell doesn't demand anything. :-)  If you write the documentation for 
> people who don't study category theory, I'm sure Haskell won't object.

Hmm... Do you have *any idea* how many monad tutorials there are?

Not that monads are complicated. They're just very abstract, so it's 
kinda hard to explain what they "are".

Imagine trying to explain what a number "is" to somebody who doesn't 
already know. Well, I mean sure, the integers are easy enough. But what 
about negative numbers? Fractions? Irrationals? Transcendentals? 
Imaginary numbers? Hmm... actually, this is pretty hard!

And yet, most people wouldn't think twice about using "numbers". So it 
can't be that hard...

I think perhaps that's Haskell's problem. It's a language which excells 
at abstracting things, with the result that the standard libraries are 
chock-full of constructs so abstract that they can only be named after 
terms from mathematics. And even if they weren't, it would *still* be 
stupidly hard to explain what they're for...

I guess Haskell will never be popular. :-(

Post a reply to this message