
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