intimidating terminology (was: Re: [Haskell-cafe] Time for a new logo?)

wren ng thornton wren at freegeek.org
Thu Dec 18 21:23:29 EST 2008


quoth Andrew Coppin:
> quoth Tristan Seligmann:
> > quoth Andrew Coppin: 
> > > 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.)

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


More information about the Haskell-Cafe mailing list