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

On 10/30/06, Jon Fairbairn wrote:

On 2006-10-30 at 14:03+0100 "Josef Svenningsson" wrote:

...

On 10/29/06, Jon Fairbairn wrote:

...

I don't agree with the methodology... Firstly, while extant code tells you how things have been used, it doesn't tell you how they /should/ be used. Second, I suspect that the majority of current Haskell code was written by novices -- I don't mean anyone any disrespect, it's just that it takes quite a long time to become an expert, the number of new novices has been increasing rapidly and the people who have known Haskell long enough to be experts probably nolonger write so much code: they get their students to do it :-). [How many of the cases you found should have been foldr (.) id etc?]

Of course there is a risk of being influenced by bad coding principle when using this methodology. But do you think that this is what happened in this particular case?

No, I'm not talking about bad code in this case -- I don't see anything at all wrong with writing "concat . intersperse "blah"", I'm complaining about the methodology in general. In this case I could even argue that your data supports my position! How many of those occurrences of "concat . intersperse x" are in the body of a definition of intercalate (by whatever name)? Out of 100 results, there's the join in ByteString, joinList in Pugs-6.0.1 (but then there are instances of the idiom rather than joinList in later versions of Pugs), a join_with in FreeArc, and that's it. So most of those programmers (and my guess would be that it's not really enough to mean much) were sufficiently happy with intersperse not to bother abstracting away from it.

There /are/ several definitions of the form "spacify = concat . instersperse " "", which also seems reasonable.

...

I challenge you to go through all the search results and report any bad code that you find so that we can avoid being influenced by that.

Given that that's not my complaing, I don't think I need to, but since I had to go through to see how many were defining intercalate I did find this comment "this is hideously broken, actually" in one, which might just suggest bad code ;-)

...

Then there is all the good code that *hasn't* been written but perhaps should have been and therefore was excluded from the search. If you feel that that's what happened here I ask you to put forward concrete examples which we can learn from.

That just seems like an unfair challenge. How am I supposed to come up with a programme that one might want to write for which intersperse is exactly the right abstraction? I've no idea what programme that might be!

You said that you didn't like the methodology. What I wanted to know was exactly how you thought that it had gone wrong in this particular case. The challenges I gave you was only meant to apply if you subscribed to the particular objections that I suggested. I'm sorry if I was unclear about that.

...

As for you second objection. To me it seems that because you don't like the outcome of the code search you declare the programmers who wrote the code to be immature.

Now that's a gross mischaracterisation of my second point! Let me recast it in a way that insults noone but me: Every line of code that I have ever written was written by someone less experienced that I am now. So I don't want to use that code in deciding how I /should/ write code in future. This is essentially the is/ought problem in philosophy. If your argument had been that all these uses could have been written more concisely using intercalate, I couldn't have disputed it, but I would still have made the argument I did about not giving names to small functions. Instead, you are trying to argue that they ought to have been written using intercalate because it's the right abstraction, and whether or not that conclusion is true, the data neither supports nor undermines it.

How do you find new abstractions? A simplified description might be: You look at previous work and see if there is a pattern emerging. When you spot a pattern you give that a name. And there you have it, a new abstraction. Do you disagree with this way of working? We learn from what we have done before and find new and better ways of doing the same thing. We spot new structures and abstractions and learn how to think about things at a higher level. I think it is a very sound principle to look at old code and find new a better ways of writing it. Indeed, if I wrote the code I was probably a lesser programmer at the time I wrote it. But that doesn't mean that I cannot learn from the code and improve it, does it? Or do I misunderstand you again?

...

...

I don't know about natural. Looking back at the 25 year old Ponder list_ops library, I find that I defined

join_with filler l1 [] = l1 join_with filler l1 l2 = l1 ++ filler ++ l2

and then

flatten_with filler = foldr (join_with filler) []

which is another way of writing intercalate.

Nice!

But I should add that it's a subtly different function, in case anyone didn't notice.

Indeed. To me flatten_with seems less usable than intercalate. But that's just my initial impression. Do you have thoughts on its merits vs. intercalate?

...

So you're suspecting that people would define their own intersperse in many different ways. I don't see how that fits in our current discussion. No one is proposing to remove intersperse.

Oh, I thought what you were proposing was that intersperse would fall out of use, so there would then be no point in having it in a library. Having both of them is definitely an instance of more vocabulary for little gain.

...

If people do find a need for intersperse then they should go ahead and use it. My argument is that people *don't* use intersperse, at least not without concat, and that that idiom will hopefully be replaced with intersperse.

But why? You hope for this, yet I thought you agreed with my general point that adding library names for short idiomatic constructions was counterproductive.

I agree that my line of reasoning can be a bit confusing here. The gist of the problem is that, due to backwards compatibility, intersperse will not be removed from the library in the foreseeable future. So we're going to have both intersperse and intercalate in the library. Unfortunate, indeed. But in the minds of the programmer (at least if his name is Josef) intersperse will be replaced with intercalate, and intersperse will fall out of use. I agree that it is not optimal to have both intersperse and intercalate in the library. But I'd rather have that than not have intercalate since I find it so useful.

...

But I personally find intercalate very useful and common enough to warrant a name. And apparently so does many others.

[...]

...

I'd like to come to some sort of conclusion. Judging from the response I got from my suggestion to include intercalate in the library it seems there is a clear majority in favour. And then there is you and a few others who disagree. With the new submission guidelines we should strive for a consensus about patches. How do you suggest we proceed?

For the case of intercalate, if everyone who is in favour of its inclusion has read my arguments and remains unswayed, then it should surely go in. I'd like to think that the points I'm making would have some effect, but if they don't, at least I get my choice of name!

OK. I do appreciate your comments and they have been duly noted. And yes, you did get to choose the name :-) All the best, Josef