Kent M Pitman <email@example.com> wrote:
| Cool quote. I've heard similar things said about Lisp programmers in other
| languages--that even when they don't have Lisp to work in, they still
| benefit from their training in how to think and correspondingly how to
| structure code to be robust.
Not just robustness, but also benefit from a Lisp view of algorithms.
Some time back, I had to help a co-worker with a problem in a Unix kernel
ATM driver, which is of course written entirely in C. The guy I was helping
had been struggling for some time with a nasty little cell-scheduling
(bandwidth allocation) algorithm. After I finally figured out just what
he was trying to do, it became suddenly clear to me that one piece of it
was just crying out to be implemented as a higher-order function which
would be passed "closures" (which in C can be faked with a two-word structs
containing a data pointer and a function pointer). Rewriting the code that
way simplified it enormously. Had I not been exposed to Lisp it would have
been unlikely that either of us would have seen the "obvious" rewrite.
p.s. I've noticed a few "functional" ideas cropping up in other networking
code, especially dealing with hash tables, which often have some sort of
MAPHASH equivalent. Though since closures per se aren't yet a common idea in
C code, the iterator calling sequence is usually defined to pass not only
the "key" and the "value" to the argument function, but also to pass though
one or two opaque cookies that were handed to the iterator. These allow a
kind of "closure environment" for the argument function.
Rob Warnock, 31-2-510 firstname.lastname@example.org
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043