Express What, not How.
Raffael Cavallaro
raffaelcavallaro at junk.mail.me.not.mac.com
Wed Oct 15 09:42:02 EDT 2003
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.
More information about the Python-list
mailing list