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