Express What, not How.

Raffael Cavallaro raffaelcavallaro at junk.mail.me.not.mac.com
Fri Oct 17 08:28:14 EDT 2003


In article <87ad80iets.wl at strelka.synthcode.com>,
 Alex Shinn <foof at synthcode.com> wrote:
> My point is the
> result of applying the HOF gives us "run quickly" which is itself a
> function, and an anonymous one at that because "run quickly" is not a
> name but a visible application of an HOF. 


I have no problem with a HOF, as long as the HOF corresponds to 
something in the language of the problem domain. But it doesn't here. I 
think it is telling that your example is taken from the problem domain 
of computer science (memoization of functions), not that of the domain.


>  It's exactly equivalent to
> 
>   (memoize run)

If we were writing a program that simulated people running and swimming, 
it's very doubtful that "quickly" would mean "memoize." "Quickly" would 
mean, "with-increased-framerate," or something similar. (Note that 
with-increased-framerate would almost certainly be a macro).

In domains outside of functional programming and mathematics, the 
concepts of the problem domain don't usually map to applicable HOFs. 
People fall in love with HOFs because they are great tools for lower 
level implementation. But I don't think they usually map well to the 
concepts of problem domains other than mathematics and computer science. 
Named functions and macros let us capture the power of HOFs inside a 
vocabulary _and_ syntax that matches the problem domain.




More information about the Python-list mailing list