Ketil Malde wrote:
The rationale for having long names is that you have too many names,
and too large a scope to keep track of them all in your head. Needing
long names is a symptom that your code is too complex, and that you
should refactor it.
Well, yeah. In Haskell, functions tend to be rather shorter than in
procedural languages, so there's less call for dissambiguation because
there are fewer variables in scope.
The other problem with "descriptive" names is that it is not
automatically checked by the compiler, and thus it often ends up being
misleading. Incorrect documentation is worse than no documentation.
That's true enough.
Nobody is going to realise that "[x]" means a list.
And C is utterly incomprehensible, since from my Pascal background, I
just *know* that curly braces denote comments. Come on, expecting
somebody to understand a language without an extremely basic
understanding of fundamental syntactical constructs is futile.
Point taken. I still think "List x" would have been clearer, but nobody
is going to change the Haskell Report now...
well you can see why people are getting lost! ;-)
Yes, by refusing to adapt to any syntax but the single one they know.
Some people will glance at Haskell and think "hey, that doesn't look
like source code, I can't read that". But given the number of times I've
explained all this stuff, you'd think one or two people would have got
it by now...
Only if you can figure out that "Map" means what every other
programming language on the face of the Earth calls a
"dictionary". (This took me a while!)
Except for where it is called an "associative array" or "hash table"?
Terminology is inconsistent, Haskell happens to draw more of it from
math than from other programming languages.
Heh, let's not argue over technical terms... ;-)
Most people seem far more confused by what a "fold" might be.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
