Express What, not How.

[Raffael Cavallaro]

In article <9d140b81.0310151301.4b811dfa at posting.google.com>,
 ddarius at hotpop.com (Darius) wrote:

> The reason people are attacking your posts is because the above has
> NOTHING to do with anonymous functions.  This advice should be
> followed independent of anonymous functions.

You're misreading those who have argued against me. They seem to think 
that this advice should _not_ be followed in the case of anonymous 
functions. I.e., the anonymous function camp seem to think that 
anonymous functions are such a wonderfully expressive tool that they are 
more clear than _actual desriptive function names_.

I agree with you; this advice should be followed, period (well, it is 
_my_ advice, after all). But advocates of a particular functional style 
think it is perfectly alright to use the same unnamed functional idiom 
over and over throughout source code, because functional abstractions 
are so wonderfully expressive. They think it is just fine to expose the 
implementation details in code locations where it is completely 
unnecessary to know the implementation specifics. 

How else can this be construed?

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

> A name is an extra level of indirection. You must follow it to be
> 100% sure what the function means, or to understand what does it really
> mean that it does what it's named after. The code also gets longer - not
> only more verbose but the structure of the code gets more complex with
> more interdependent parts. When you have lots of short functions, it's
> harder to find them. There are many names to invent for the writer and
> many names to rememner for a reader. Function headers are administrative
> stuff, it's harder to find real code among abstractions being introduced
> and used.

In other words, don't use names _at all_ if you can avoid them. Just 
long, rambling tracts of code filled with anonymous functions. After 
all, you'd just have to go look at the named function bodes anyway, just 
to be _sure_ they did what they said they were doing. (I wonder if he 
disassembles OS calls too, you know, just to be sure).

Really I personally think they are often just enamored of their own 
functional l33tness, but you'll always have a hard time convincing 
programmers that their unstated preference is to write something so 
dense that only they and others equally gifted in code decipherment can 
grasp it. Many programmers take it badly when you tell them that their 
job should be much more about communicating intent to other human beings 
than about being extremely clever. As a result of this clever agenda, an 
unmaintainably large proportion of the code that has ever been written 
is way too clever for its own good.