Express What, not How.

[Raffael Cavallaro]

In article <eg7k35mpgu.fsf at vipe.ii.uib.no>, ketil+news at ii.uib.no wrote:

> Anonymous functions *can* be more clear than any name.

This belief is grounded in a desire to keep the program's language close 
to the programming language, rather than moving the program's language 
toward the problem domain. This resistance is, I suppose, understanable. 
After all, the programmer's expertise is the language of the programming 
language, not the language of the problem domain. It is, at least at 
first, easier for him to talk in the language that he knows than one 
that is new to him. Nevertheless, this is exactly what he must do if he 
is to write clear code. The reason we see 300 line function bodies is 
that many programmers resist expressing the solution in the language of 
the problem domain, preferring instead to write in an idiom that they 
already understand, the programming language.

The higher level abstractions of a complex piece of software will, of 
necessity, be concepts in the problem domain. These concepts, 
representing both entities, and the relationship and interactions among 
different entities, will almost certainly already have well established 
names in the problem domain. For those that do not, the programmer 
should take the time to find apt descriptions of these entities or 
interactions _in_the_language_of_the_problem_domain_. These problem 
domain names are the appropriate units of the language that the software 
should be written in. Named functions and macros are the appropriate 
labels for the programmer's software definitions of the concepts of the 
problem domain, not anonymous functions.

Unless the problem domain is functional programming itself, the language 
that the program is written in should consist of names taken from the 
problem domain, not anonymous functional interactions.

At some low level of abstraction, when building the functionality of the 
named functions and macros that correspond to the concepts of the 
problem domain, the programmer will, of course, need to specify 
implementation. These implementations will, where appropriate, use 
anonymous functions.

However, once we get above this lower level of abstraction, we will be 
dealing with concepts from the problem domain, which _have_names_. These 
names from the problem domain, not anonymous functions, and not the 
keywords/built-ins of the computer language,  should be the language the 
program is written in.

Moreover, even at the lower levels of abstraction, we will be passing 
through other well explored problem domains, such as arithmetic, string 
mainipulation, etc. These domains _also_ have preexisting named 
concepts, which can and should be used by the programmer. Most decent 
languages have built-in functions or keywords or operators for some of 
these things. For others, the programmer can and should take the time to 
define named functions and macros for arithmetic, string manipulation, 
etc. operations that correspond to concepts in each of these problem 
domains.

This stands in direct opposition to those who think that software should 
seek to _avoid_ names whenever possible. I, on the other hand find this 
simple equation is true:

Names = Clarity
(specifically, names taken from the problem domain)

Some posters here have replied that this is just "obvious," and true 
independent of the issue of anonymous functions. But the two issues are 
_of_necessity_ related, because you cannot have both names and anonymity.

It seems as if some here believe that names = tedium, or names = 
prolixity, or names = exra work. But disdaining this work of finding 
appropriate, descriptive, names from the problem domain, is a recipe for 
obfuscated code. Worse, it is a recipe for failed software projects. The 
failure to find good names from the problem domain indicates a failure 
to properly understand the problem domain in its own terms. Failure to 
understand the problem domain in its own terms means that the program's 
design is almost certainly fatally flawed.

Again, this will be decried as "obvious." However, what should be 
obvious is that we cannot have both names, and anonymity.