Subject: Re: Lisp and Scheme.....
From: Erik Naggum <erik@naggum.no>
Date: 2000/01/27
Newsgroups: comp.lang.scheme,comp.lang.lisp
Message-ID: <3157978564787770@naggum.no>
* Chung-Lin Tang <u8832022@cc.nctu.edu.tw>
| How much does Lisp and Scheme differ?
completely. two completely different cultures, two completely different
measures of success, two completely different concepts of elegance and
usability, two completely different sets of semantics for superficially
similar forms of expression. as languages, they have less in common than
Ada and Perl. as user communities, only the Scheme people believe that
they are using a Lisp, based on the belief that retaining parentheses and
prefix form is enough to remain a Lisp -- and, of course, the desire in
the Scheme community to convert people to their pure religion, a desire
you won't find in any other Lisp-derived community, especially not those
of the languages who have any purity to boast about. Scheme has the
world's most elegant, yet closed, language specification, while the other
Lisp family members focus on elegant language _use_ and _extension_.
while this may be taken as an exaggeration, it's less of an exaggeration
than the ignorant opinion that these languages are substantially the same.
Scheme is worth learning well -- no other language has a more succinct
way of teaching you programming language concepts, but the language also
has the most succinct way of teaching you language design mistakes if you
listen critically to its many design decision and don't accept them as
the gospel they are attempted sold as.
Common Lisp is worth knowing and using well -- no other language has a
more succinct (yet supremely readable) expression of complex, real-life
programming tasks and problems, and your ability to build your language
towards your problem is its most unique strength, yet the very concept of
building a language suitable to a problem is foreign to most other
languages and programming cultures.
incidentally, Scheme was a very good example of what happens when you
take a particular, favored programming methodology and hard-code it into
a language design -- you find that as you optimize your design too much,
you lose the freedom to do anything else with similar ease without having
to create _another_ and separate mini-language, and this means writing
all the support machinery all over again for every langauge -- a favored
academic exercise worth approximately nothing outside academia once you
get the degree.
#:Erik