Express What, not How.

[Alan Gauld]

On Thu, 16 Oct 2003 19:06:00 GMT, Raffael Cavallaro
<raffaelcavallaro at junk.mail.me.not.mac.com> wrote:
> 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.

Do you have any objective evidence to suggest that this is true?
What proprtion exactly is due to this? The reason I ask is that
most of the long functions I have seen have been products of the
algorithm being implemented. If an algorithm takes 300 lines to
express it should be expressed as 300 lines. I have *never* seen
a long function that is the result of a programmer avoiding using
user vocabulary!

Equally I see no evidence whatsoever to suggest that users
express requirements in short chunks - usually the opposite, we
get presented with long complex prose describing a convoluted
business process and the programmer has to split that into its
natural chunks during analysis!

If anyone has done any research to connect long functions with 
ignoring of user language I'm unaware of it and would be most
interested in seeing it.

> The higher level abstractions of a complex piece of software will, of 
> necessity, be concepts in the problem domain. 

Not necessarily(*), but I would agree that usually they are, but
at the lower levels the solution space may bear no resemblance to
the problem domain at all!

(*) For example where the solution architecture is based on a
mathematical technique which would be impractical in a manual
business process but is entirely practical using computing power.
As a somewhat dated example - the processes used in computer
crytography for example being entirely different to those used in
manual cryptrography. There will be some concepts in common 
but many will be entirely novel.

> 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.

In the general case I agree completely but a blanket statement
that it is always true is absurd. There are many cases when a
programmer is dealing with issues that simply don't arise in the
human scenario. Anonymous functions are often used in 
scenarios where a name is meaningless. Even in business processes
it is not unusual to find processes with names like JDI(Just Do
It) or DWN (Do Whatever's Necessary) to deal with extraordinary
scenarios. (Although ironically these are rarely the ones which
require anonymous funtions in code!)

> At some low level of abstraction, when building the functionality of the 
> ...
> implementation. These implementations will, where appropriate, use 
> anonymous functions.

Ah, we do agree at this level. So your point only applies to
"high level" functions. The issue then becomes one of deciding at
what point the solution and problem domains separate.

> However, once we get above this lower level of abstraction, we will be 
> dealing with concepts from the problem domain, which _have_names_. 

Usually, but not always. Or often highly generic names which are
best implemented using higher order programming techniques
involving anonymous names.

> 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

Again, in general I agree. But if the name is f and it is only
used for as long as it takes to convey a single use function into
the argument list of another function then I find the naming to
be of little or no value.

> 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.

I'm not sure I agree there. It happens in the real world all the
time. (Consider Internet Chat Rooms! Many users there desire
anonymity while using a name which may not be their identity.
Indeed they achieve anonynimty through their false identity!)

> prolixity, or names = exra work. But disdaining this work of finding 
> appropriate, descriptive, names from the problem domain, is a recipe for 
> obfuscated code. 

I agree that good names are a good thing and time should be spent
considering appropriate ones but...

> Worse, it is a recipe for failed software projects. 

Bad naming is rarely if ever the reason for failed projects. It
may contribute by slowing down testing or integration and thus
causing estimate failure (the most comon reason for failed
projects) but naming alone is not enough to cause a failure IMHO.

> 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.

Insofar as the problem domain is reflected in the solution space
I agree. Certainly a programmer who does not understand the
vocabulary of his end user is unlikely to create good solutions.

Naming is important where a name aids understanding. If a name is
just there as a marker it serves no purpose. I agree that this
rarely happens at a high level in the design but I think it
happens at a higher level that you suggest. Not often, but often
enough to prevent blanket assertions being made.

Alan G.

Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld