[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: s-exprs + prototypes

On Sat, 21 Jun 2003, Anton van Straaten wrote:

> Given all this, a question that could be asked, which I do mainly
> rhetorically and for thought-provoking purposes, is why a language would
> implement something as simple as a pair in terms of a much more complex
> structure, such as an OO object or class?  Isn't that a little like
> implementing a scooter by strapping a platform with handlebars to the top of
> an SUV?

I'm not going to get directly involved in this dicussion, but I find the
following quote from Alan Kay's "The Early History of Smalltalk" to be
interesting in this context; perhaps others will as well.

"I could hardly believe how beautiful and wonderful the /idea/ of LISP
was.  I say it this way because LISP had not only been around enough to
get some honest barnacles, but worse, there were deep flaws in its logical
foundations.  By this, I mean that the pure language was supposed to be
based on functions, but its most important components -- such as lambda
expressions, quotes, and conds -- were not functions at all, and instead
were called special forms.  Landin and others had been able to get quotes
and conds in terms of lambda by tricks that were variously clever and
useful, but the flaw remained in the jewel.  In the practical language
things were better.  There were not just EXPRs (which evaluated their
arguments) but FEXPRs (which did not).  My next question was, why on earth
call it a functional language?  Why not just base everything on FEXPRs and
force evaluation on the receiving side when needed?  I could never get a
good answer, but the question was very helpful when it came time to invent
Smalltalk, because this started a line of thought that said ''take the
hardest and most profound thing you need to do, make it great, and then
build every easier thing out of it''.  That was the promise of LISP and
the lure of lambda -- needed was a better ''hardest and most profound''
thing.  Objects should be it."

  ACM SIGPLAN VOL. 28 No. 3 March 93 pp.69 - 75