You can't
teach "standard C" without picking a standard, too. There
are at least three (K&R v1, ANSI C, and C99) and probably more [...]
Yes, but
similarly my point is that you can't teach BOTH CL and
Scheme in one syntax,
You can come pretty close. A whole lot of the syntax is the same
(parentheses-surrounded prefix function calls, for example), and much
of the rest is trivial details of the "CL spells this foo, Scheme
spells it bar" sort. It's only when you dig a lot deeper than most
novices will that you start seeing major differences.
and trying to teach "generic" Lisp beyond
the theoretical
underpinnings covered in Graham's "Roots of Lisp" would be kind of
weird and rather unhelpful, wouldn't it?
I dunno. I learnt Lisp long before I learnt anything about the lambda
calculus. Just as we teach kids to add and multiply before we teach
them the underlying theory (this is why the New math was such a
disaster - indeed, many people never learn the underlying theory
because they have no reason to care about it), I see nothing wrong with
teaching Lisp without teaching the underlying theory.
It's true that you can't be really good at Lisp without at least a
little of the underlying theory, but you don't need it in the form of
theory; what you need are the abstractions, without necessarily
understanding their theoretical underpinnings. It's perhaps better if
you do, but that's true of any field; just as I'm a better Lisper for
knowing a little about the lambda calculus, I'm a better C programmer
for knowing a little about complex analysis and Taylor series and error
analysis and combinatorics and many other things. Indeed, I would
argue that some familiarity with the lambda calculus will make you a
better programmer even if you never touch Lisp. Much the same is true
of combinatorics and all those other fields.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at
rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B