Express What, not How.

[Raffael Cavallaro]

In article <pan.2003.10.15.08.18.41.116193 at knm.org.pl>,
 Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:

> You contradict yourself. First you say that "any anonymous function syntax
> is undesirable", and they you accept anonymous functions in the middle of
> higher level abstractions.

and
In article <tmpu51-n3q.ln1 at proper.ptq.dyndns.org>,
 Ken Shan <ken at digitas.harvard.edu> wrote:

> So perhaps we should have the programming language outlaw anonymous
> functions that are more than 4 lines long...


I thought it was obvious that I was not advocating eliminating anonymous 
functions entirely, since I said they should be used inside named 
function bodes.

To be completely clear, I'm advocating only using anonymous functions 
when two conditions are met:

1. When the functionality provided is _unique_. If that which the 
anonymous function is performing is also done elsewhere, especially if 
it is done in several different places throughout the code, then that 
anonymous function should be recast as a descriptively named function or 
macro.

2. If it is necessary to show, at that _particular_ source location, 
_how_ a piece of functionality is provided. If the reader doesn't need 
to know _how_ things are implemented in that _particular_ source 
location, we should use a descriptively named function or macro instead.

I find that many programmers overestimate the "uniqueness" of their 
anonymous functions. They tend to repeat the same anonymous function 
idiom in many places. Rather than come up with a descriptive name for 
_what_ they are doing, they clutter a higher level abstraction with low 
level details about _how_ they are doing it. These should be recast as 
descriptively named functions or macros. 

Many programmers use anonymous functions in places where it is simply 
not necessary to know _how_ things are being implemented. In general, we 
shouldn't provide the readers of our code with information about its 
implementation that isn't necessary to know in the current context. 
Doing so obscures the current intent, and sprinkles identical 
functionality, which may need to be modified later, in many locations 
throughout the program.

To use the example that started this sub-thread, when I'm reading that a 
list or a vector has an offset added to each element, I don't need to 
know that the add-offset functionality is implemented by means of map. 
That piece of information can more safely, and more clearly, reside in a 
separate named function, add-offset, which may (or may not) use map to 
provide the add-offset functionality. This is especially true, as is 
often the case, if add-offset's functionality is used in many locations 
throughout the program. We get clearer client code, and easier 
maintenance/change if that bit of repeated functionality is isolated in 
a single, descriptively named, function or macro. Then, in that 
_particular_ source location, (defmethod add-offset...), we _do_ need to 
show _how_ add-offset is implemented. So we use anonymous function 
syntax there, as needed, in this case, with map and lambda.