Tristan Seligmann wrote:
* Andrew Coppin <andrewcop...@btinternet.com> [2008-12-16 20:23:50 +0000]:
Sure, there are many concepts in Haskell which just aren't found
anywhere else. But monads? Catamorphisms? Coroutines? Couldn't we think
up some less intimidating terminology?
The problem is that "less intimidating" terminology generally seems to
mean inaccurate or misleading terminology.
I'm not sure I agree with that.
Sure, simplifying things *can* make them less precise. But I don't
believe it is always necessarily so. And I think we could try a little
bit harder here. (Nothing too radical, just some small changes.)
They aren't concepts that
aren't found anywhere else, they're concepts that *are* found elsewhere
(category theory, among other places), that's why they have those names.
And who knows category theory? Almost nobody. If you insist on naming
stuff after things that nobody will have heard of and which sound highly
technical, you're going to seriously limit your potential audience.
(Hylomorphisms verses epimorphisms. Anybody remember which is which?)
(Also, "coroutines"? Seriously? That's hardly an obscure term in
programming circles.)
Well now, I'm curios. I've been writing computer programs since I was 9
years old. I hold a diploma *and* an honours degree in computer science.
And I have never even *heard* of a coroutine. To this day I still don't
know what it means. I rather suspect I'm not the only "programmer" on
earth who finds themselves in this position. ;-)
{-# LANGUAGE ExistentialQuantification #-}
Hmm, now if this was Perl or something, that would be
HiddenTypeVariables or something. Much less fearsom-sounding.
Also much less informative, and less accurate.
How so?
Turning on this extension allows you to "hide" a type variable from the
RHS of a data statement from appearing on the LHS. That's *exactly* what
this extension does. What could be more descriptive? (Without launching
into advanced logic theory anyway...)
The fact that Haskell
embraces its mathematical basis instead of trying to completely
obfuscate it away is not a bad thing, in my opinion.
I don't see how having a pronouncible name for something is
"obfuscation". It's good that Haskell's mathematical foundations show
through, but it would be bad if Haskell were completely opaque without
first doing a postdoc in category theory. Technical terms are only
useful to those who already know what they mean, after all.
(We don't talk about "single-valued total relations", we talk about
"functions". Because nobody knows what the heck a single-valued total
relation is, but most people immediately "get" what a funtion is.)
But then, I guess that's what you get for a lanuage designed by a
committee of university professors. ;-)
At any rate, if we're to have a logo, let's not have one which actively
*promotes* the notion that Haskell is complex and difficult and that
only theoretical physicists need apply...
I think you're reading way too much into a logo.
The current logo is basically a circle plus a whole heap of mathematical
symbols. That doesn't really say "hey, this stuff is fun, come on in!"
It says "this is for maths nerds only". (Which isn't actually true, in
my opinion. But the current logo gives that impression.) I'd like our
new logo to do better in this direction, that's all.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
