Subject: Re: Lisp and Scheme.....
From: Erik Naggum <>
Date: 2000/01/27
Newsgroups: comp.lang.scheme,comp.lang.lisp
Message-ID: <>

* Chung-Lin Tang <>
| 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.