Express What, not How.

David Rush drush at aol.net
Mon Oct 20 16:16:51 EDT 2003


I've just about decided to killfile this whole thread, but I can't
let this one go by. Two unsubstantiated assertions do not make a bad 
programming practice, no matter how hard you try.

On 19 Oct 2003 19:22:04 -0700, Raffael Cavallaro <raffael at mediaone.net> 
wrote:

> The problem I see with the use of the typical anonymous functional
> style is twofold:

How much programming have *you* done with anonymous functions? Or is this 
complaint based on your esthetic reactions to a series of contrived 
examples in usenet posts?

> 1. The same functional idiom is repeated, but not abstracted (i.e.,
> not named). This leads to unnecessary "programmer inlining," that is,
> writing out the implementation everywhere it is used, rather than
> naming it once, and using the name everywhere else.

Not by this heavy user of anonymous functions. In fact one of the main
uses I have for anonymous functions is to *avoid* code duplication by
parameterizing over entire categories of functions.

Cut & Paste programming is bad practice in any language. IME, functional
programmers do it *less* often than those from other communities.

> 2. The anonymous functional idioms map well to domains such as
> arithmetic, mathematics, and functional programming itself. These same
> idioms don't map so well to other domains. The more abstract the
> program becomes (that is, the closer it moves to the problem domain,
> and the farther it moves from the low level arithmetic and functional
> abstractions) the less the anonymous functional idioms will correspond
> to the existing concepts and vocabulary of the problem domain.

Again, I disagree heartily. I use HO&AFs to enable greater levels of
abstraction since they allow me to abstract *outer* components of
functions while I pass in the site-specific portions. Control-structure- 
like
functions are only a fairly trivial example of this kind of thing, but
I have in a mail-processing application 2 functions IF-FROM-LINE (used in 
mbox file processing) and RFC822-COLLAPSE-HEADER (used in RFC822 header
processing) which both implement algorithms which are parameterized
by functions. This is vaguely similiar in spirit to the visitor pattern
from OO land, but much more flexible. Both of these functions are used
in multiple contexts where the anonymous functions contextualize the
operations performed under specific conditions in their implemented
algorithms. These operations have (so far) been strictly one-off animals.
In the event that I ever feel a need to re-use one of them I will simply
lift the anonymous function from its original source location, give it
a top-level name et voila - instant reuse.

david rush
-- 
(\x.(x x) \x.(x x)) -> (s i i (s i i))
        -- aki helin (on comp.lang.scheme)




More information about the Python-list mailing list