Posted: Mar 18, 2012 2:02 am
mizvekov wrote:Yeah that came out badly. What I meant was, in more broad terms, what kind of mistake was made so that it would start losing popularity. My own experience in the matter seem to be that they are not making it look interesting to CS students, as it happened to me, but that could be very biased. But the fact is, none of my peers became interested even slightly in LISP.
But why is that? Bad PR? is LISP specially hard to teach to the inexperienced?
Jumping in here.
I learned LISP in my first semester at MIT. LISP was the Big Deal there at the time (late 1970s), and that's what they taught the frosh (now I hear they use Python, which is very LISP-like but with syntax). I had already learned BASIC (with line numbers), COBOL, Tutor (later renamed PAL), and Z-80 assembly.
LISP was very badly taught at MIT. All the examples had unnecessary PROGs all over the place. The first example of recursion they gave was the Fibonacci sequence, which is bad, because the iterative solution is so obvious and obviously better. (A much better first recursion is the Towers of Hanoi, which is truly magical.) It took me a few years to get into LISP, but when I did, I really liked it. One of my main mental health exercises when I was stressed was to write a small LISP implementation on a new architecture.
LISP is extremely beautiful. Common LISP, however, has so much stuff in it that it strikes me as extremely unwieldy. I cannot remember who, but somebody said that every significant implementation contains a bug-ridden implementation of about half of Common LISP. I think this is true. The internal ideas of LISP and the way it handles memory are quite good, and even in programs in C and C++, it makes a lot of sense to write something like LISP internally.
But that beauty also leads to what Richard Feynman called "the computer disease." That is, computers are so wonderful that you play with them. Then you get into this exaggerated purity thing, which can stop a large project as fast as the sudden death of all people involved.
People who get really into LISP seem to become hostile to everyone else. So LISP didn't really stay with the times. It sort of lives in its own special world. It doesn't have to be this way at all; this is just what happened. I saw this in one of the posted (by @VazSkep, IIRC) links, arguing that LISP wouldn't help you with Perl, but you shouldn't be doing anything in Perl anyway. This, I think, represents a misunderstanding of what Perl is for and a failure to understand that writing beautiful programs isn't always the right thing to do.
During the 1980s, some things were happening in CS. Computers, particularly microprocessors, were moving toward stack-based architectures. O-O was becoming more popular. So was C, after a brief flirtation with Pascal (another popular first language of the time). Lots and lots of people were adapting LISP, which was part of the problem. There was little standardization. Then, when they were standardized (such as in Common LISP), they were suboptimal.
The early work in LISP, such as frames, lends itself neatly to O-O. What got put into Common Lisp was a model far too much like that of ADA. Very powerful and workable, it still doesn't lend itself well to the object magic where you actually get the improvements in programming speed and maintainability.
I really like Scheme (the "uncommon LISP" but to many LISP aficionados "not LISP"), but it has the 95% problem. It's very clean and wonderful, up to a point. With a little work, it could be perfect, but then what happens is people keep trying to implement it. One of the interesting things is that it seems like it is great for a stack-based architecture, until you get to call-with-current-continuation, and then you realize you should have adopted a different approach.
Then what you get is a bunch of implementations, none standardized. The schemes I've seen on .Net are particularly botched. Everyone has their favorite, and it becomes unavailable in a couple of years.