Express What, not How.

[Alex Shinn]

At Fri, 17 Oct 2003 12:28:14 GMT, Raffael Cavallaro wrote:
> 
> 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.

Actually, my problem domain more often than not *is* computer science,
but you could also stick strictly to human language or whatever suits
your fancy.

> 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.

I don't see how a framerate is less computer-specific than memoization.
If you want to stay close to the original human language then it would
simply mean the act of running faster than usual.

> (Note that with-increased-framerate would almost certainly be a
> macro).

Not necessarily.  In Scheme with- forms are almost never macros, and are
almost always passed anonymous functions as arguments.

> 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.

You're switching to macros and HOFs when we were talking about anonymous
functions.  If you are seriously arguing against the use of HOFs in
general then I think you have a lot to learn.  Learn a Lisp (Scheme is
nice and clean) or one of the more functional languages like Haskell.
If you brought macros into the discussion with the idea that any direct
application of an anonymous function should be hidden with a macro then
I question whether your goal is really to achieve more legible code or
is just some irrational bias against anonymous functions?

If you want to program in logic as close to the problem domain as
possible, try a logic programming language like Prolog or CLIPS.  You
may be disappointed because even in these languages you have to refer to
low-level details at times.  Also you will find that an extremely useful
feature is not only anonymous functions but anonymous facts and rules.
If you want to wait until you can program explicitly in the
highest-level human language then I think you may be even more
disappointed.  Firstly because as already mentioned human language makes
heavy use of anonymous functions and unnamed concepts in general.  When
possible we combine existing ideas and use their compound forms directly
in speech without giving them a new name.  Secondly because human
language is not well suited to exact specifications, which is why when
we try to nail down rules as specifically as possible we end up with
language like legalese.

If you want to tell computers what to do in natural human language,
trusting them to learn what you mean when you're ambiguous (through a
process of correcting them when they guess wrong) then that is an
admirable dream.  But it's not programming.

-- 
Alex