Names for small functions: just say no... Re: Data.List.join

[Jon Fairbairn]

Summary: further thought has convinced me that the proper
thing to do is not to name this in a library (or other very
short functions).

On 2006-10-22 at 21:09+0400 Bulat Ziganshin wrote:
> Sunday, October 22, 2006, 7:16:28 PM, you wrote:
> 
> >> > intercalate, surely?
> >> it's a rare word that is unknown for english-guests like me

But if you type "define:intercalate" into google (даже
google.ru), you find what it means.

> > В противоположность "Monad" например?  (Apologies for
> > what is probably appalling grammar!)  
> it's correct :)

More by good luck than good management, I fear¹...

> and you found a great example - this word from math
> language is sense-less for peoples whose native language
> is not Math and makes all sorts of confusion. naming it
> Combinator or Strategy or smth like this will cut learning
> curve

Perhaps, but at the end of that new learning curve, you
wouldn't know what a Monad is, which would leave you the
poorer.

> > More seriously, the more I think about it, the more I
> > wonder if giving names to things that have such a short
> > expression[...] might not be counterproductive.
> 
> > [...] “(concat.).intersperse” might cause some head
> > scratching at first, but everything involved is
> > something that the programmer will have to learn anyway,
> > and if its use is frequent, it will become idiomatic.
> 
> once you've learned smth, it looks really easy and you may
> wonder why other stupid peoples can't understand this
> immediately. but recall how much time of Haskell learning
> was required for you to make itself familiar with such
> idioms?

That's rather orthogonal to my point. Suppose we chose
"join"; learners would find that join is like it is in other
languages, and then find that there's also a join in Monad,
and that would be confusing, which is counterproductive.  If
we call it intercalate, there's the slight benefit of
widening some people's English vocabulary, but that's not
worth that much. If someone knows what they want to do (and
already knows the word), then they might well check to see
if there's a function called intercalate in the libraries,
which again is a slight advantage.

If we don't give it a name, learning to read “concat
. intersperse something” (which is more common than the
formulation I gave above) means learning intersperse, concat
and compose -- all of which are invaluable Haskell. But if
we call it whateverify, there will still be programmes
around that use concat with intersperse (I don't plan to go
through all my old code and use the new name, and I doubt
many would). Furthermore, for a seasoned Haskell programmer
who wants to (for example) concatenate a list l with commas
between the elements, what springs to mind is “concat
(intersperse ", ") l” and it comes to mind so quickly that
looking for a library function to do it would seem like an
onerus additional task.  Of course, if that construction
occurred several times in a programme, they might choose to
call it "commas" or something for conciseness, but that sort
of naming for brevity is a separate issue from putting
something in a library. 

To consider a different example, while you might reasonably
expect a library function to compute the RMS of a list of
values, I don't think you would bother to look for a
function to compute the sum of the squares of a list,
because it's just “sum . map (**2)”, and that's easy enough
to read.


> from viewpoint of readability for as much people as
> possible i prefer join or joinWith. join used in ruby and,
> i think, in perl. joinWith is at least readable. all other
> ways, imho, leads to building "secret language" which
> foreigners will need to learn without getting any
> advantages

but that makes my point for me. Giving names in libraries to
short functions that have a pretty much unique natural way
of being written amounts to a "secret language" (it wouldn't
matter if it was just intercalate or whatever, one new
function more or less doesn't make much difference, but
that's a small pile of stones argument). When I said that if
it's used often enough it becomes idiomatic, I meant that
one learns to read it without thinking -- that applies to
intercalate or joinWith or whatever, but the difference is
if you /don't/ already know what it means, joinWith has to
be looked up (or guessed, again I'm addressing the general
case of naming short things rather than joinWith which might
be guessed correctly quite often), whereas “concat
. intersperse foo” can be worked out by knowing relatively
primitive things.


For me, the main thing that comes out of the postings
offering different alternative names is that the "correct"
name isn't obvious. Way back before Haskell when I was a
beginner functional programmer designing Ponder, I had my
own "obvious" name for it, and that name hasn't been
suggested -- moreover, I had a function called "join_with"
that did something else! So someone who is looking for a
function to do this won't know what name to look for, and
will quite likely write it in less time than it takes to
Hoogle for it by type. That means that you'll have to learn
what “concat . intersperse foo” means anyway, in addition to
learning joinWith.


Certainly complicated enough constructions deserve library
entries, and I admit I don't know where the break even point
is, but I'm pretty sure it comes above two words and some
punctuation -- unless it's something fundamental like
composition.


[1] Russian grammar is remarkably difficult for this native
English speaker. Conversely, I'm well aware that certain
constructions in English (eg "would have been going to go")
aren't easy for Russian speakers.

-- 
Jón Fairbairn                              Jon.Fairbairn at cl.cam.ac.uk