Express What, not How.
Raffael Cavallaro
raffaelcavallaro at junk.mail.me.not.mac.com
Fri Oct 17 08:28:14 EDT 2003
More information about the Python-list mailing list
Fri Oct 17 08:28:14 EDT 2003
- Previous message (by thread): Express What, not How.
- Next message (by thread): Express What, not How.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): Express What, not How.
- Next message (by thread): Express What, not How.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list