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

[Lennart Augustsson]

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 <wren at freegeek.org> wrote:
> 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>