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