Express What, not How.

[james anderson]

"Brian McNamara!" wrote:
> 
> Raffael Cavallaro <raffaelcavallaro at junk.mail.me.not.mac.com> once said:
> > Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> >> Sometimes a function is so simple that its body is more clear than any
> >> name. 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.
> >
> >Your argument is based on the assumption that whenever people express
> >_what_ a function does, they do so badly, with an inappropriate name.
> ...
> 
> If I understand you correctly, you would insist I write something like
> 
>    nat :: Parser Int
>    nat = do {c <- digit; return charToInt c}
>          `chainl1` combineDigits
>             where combineDigits = return \x y -> 10*x+y

when i read r.cavallaro's note, i saw no proscriptions. upon rereading it i
observe a value judgement and several characterizations. perhaps the reader
somehow misinterpreted them as pre/proscriptions. pehaps if the term "force"
were replaced with "require" the b.mcnamara would agree that there is no
contraction between them and his post in reply.

...
> 
> By only naming the most reusable abstractions (and, ideally, selecting
> a set which are mostly orthogonal to one another), we provide a "core
> vocabulary" which captures the essential basis of the domain.  Lambda
> then takes us the rest of the way.  In my opinion, a core vocabulary of
> named functions plus lambda is better than a separate name for every
> abstraction.  In natural language, such a scheme would be considered
> double-plus-un-good, but in programming, I think it lends itself to the
> simplest and most precise specifications.

what is the utility in overstating cavallaro's argument, in order to set up a
straw argument which reaches a conclusion quite in keeping with the original?
perhaps, yes ther is some utility in reiterating that extreme
pre/proscriptions in either direction are counterproductive. but, that in no
way weakens his argument.

> 
> I agree with your one of your overall theses, which is that we should
> focus on the "what" rather than the "how".  Where our opinions diverge,
> however, is that I think sometimes the best way to communicate an
> abstraction is to show the "how" inline, rather than creating a new
> name in an attempt to capture the "what".
>