When accurate names for Haskell concepts already exist we should use
them (as we have tried in the past). There has been too much
invention of misleading terminology in computing already. If some
people can't handle things having the right names, well, maybe they
should try another language. (What would happen if we used the new
name principle, e.g., in cooking? Oh, cinnamon is a difficult name,
I'll call it tangy spice instead.)
-- Lennart
On Fri, Dec 19, 2008 at 2:23 AM, wren ng thornton w...@freegeek.org wrote:
quoth Andrew Coppin:
quoth Tristan Seligmann:
quoth Andrew Coppin: Sure, there are many concepts in Haskell which
just aren't foundanywhere 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.)
Consider the humble catamorphism (and anamorphism). Can you think of any
simple, descriptive, non-ambiguous name for this pattern other than the
technical name? An oft used name is fold (and unfold) which is simple,
possibly descriptive, but certainly ambiguous. For example: the fold/unfold
names are used as jargon for optimization ---in compilers for logic
languages and query planning for databases--- for inlining functions and
then 'outlining' parts after doing some reorganization. There are other
technical uses which are just as different.
The problem with simple terms for jargon is that they're all taken. When we
take everyday terms like fold, set, list, tree, category, type,
kind, sort, variety, domain, group, et cetera and reappropriate
them for technical use there are two problems. The first is that all of the
simple everyday terms have already been appropriated time and again, so
using it will often be ambiguous. The second is that the technical meaning
often does not expressly match the daily meaning, which in turn means that
these terms will often be confusing or used casually in a way that confuses
the daily and technical meanings.
It's all well and good for terminology to be non-intimidating, but for
technical terminology I think there must be a high premium on correctness as
well. Reappropriating terms which have fallen into disuse for their original
meanings (e.g. monad) or which are taken or invented from languages the
audience is unlikely to be familiar with (e.g. catamorphism) ensures that we
don't have to worry about baggage associated with those words. This is good
because it means there won't be conflicts of meaning, but it's bad because
it means the audience can't intuit an approximate meaning. Pedantic as I am
wont to be, I think the benefit outweighs the detriment, but YMMV.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
