Express What, not How.

[Raffael Cavallaro]

In article <521c61-o2i.ln1 at proper.ptq.dyndns.org>,
 Ken Shan <ken at digitas.harvard.edu> wrote:

> I'm not sure if I understand your notion of problem-domain levels.  For
> instance, in a preceding example
> 
>     amount_due = sum(item_prices) * (1 + tax_rate)
> 
> is the problem domain possibly "functions and their arguments", or is
> the problem domain possibly "customer billing"?

How about simple arithmetic, which is built into most computer languages.

However, if you do this often enough in your code (i.e., compute a 
total, then add the tax), you migh want to have a named function, say 
"total-with-tax," instead of just reimplimenting it every time you use 
it. It's simply a matter of how much of what you're doing is specific to 
the larger problem, how much is just arithmetic, using built-ins, and, 
probably most importantly, how often you'll be repeting yourself in 
exactly the same way.



[snip]
> (when do I stop?)?

When you reach the built-ins of the language, of course. No need to 
define a method called "add" in a language that has + as a built in 
function (unless you're going to overload addition to do something that 
the built-in function doesn't do yet.)

But the very telling larger picture issue is that there is such a 
reluctance to name bits of code that are going to be used more than once.