Lisp sucks, the articulate version
It's pretty clear why most Lisp books seem to infatuated with the language. It's not just because they're books about Lisp (it's perfectly possible for a book about a language to be completely dispassionate — witness K&R, which actually points out design flaws in C on occasion). Here's the argument: first of all, new books about Lisp are no longer being written, simply because even if it ever was a mainstream implementation language, it's been soundly eclipsed by C and C++ and their ilk. Lisp is now only used in niche markets like artificial intelligence research and cognitive modeling (two related fields). Therefore, Lisp books currently in existence are generally old. Therefore, they are from an age when there were few or no compelling alternatives to Lisp as an implementation language. Lisp is a very old programming language — among those in which new programs are still written, only Fortran is older. Lisp itself is from an age of strictly procedural programming languages. In a context like that, it's easy to understand why lots of Lisp books tout Lisp as a "productivity-multiplying" language. In fact, the book from which I've learned the most about Lisp (wittily entitled "Lisp"), cites the following as a reason why any computer programmer worth his salt should learn Lisp:
Lisp facilitates procedure abstraction and data abstraction. By hiding the details of implementation from places where they're not needed, Lisp makes it easier to think about the overall structure of a program.In response to that, all I'm going to do is point at Java. I hate to use Java as a shining example of anything other than suck, but there it is, a language that's actually gotten pretty widespread (more so than Lisp, at any rate) which makes procedure and data abstraction darn near mandatory.
Abstraction is the core of what programming language designers aim to do nowadays. Maybe the emphasis on abstraction is in fact due to Lisp (I can't deny that Lisp has been heavily influential on programming language design), but that doesn't change the fact that there are more modern, more readable, faster and better-designed languages nowadays that all facilitate abstraction just as well as Lisp. So that's certainly no longer a reason to learn Lisp.
Back to what I was saying, the reason that such a high proportion of Lisp books seem to argue that if you're going to learn a programming language, Lisp had darn well better be it, is that there was a time when, in fact, Lisp was the sensible choice if you had to choose one language to learn. I offer my condolences to any programmer who learned the craft during that time.
Still, though, it's undeniable that Lisp has properties shared by no other programming language today. I can't think of any language, even a niche one, that does symbol manipulation to the same degree that Lisp does. I'm sure they exist, but I don't know of any other languages that allow you to selectively specify symbols that shouldn't be evaluated. In any language that supports closures, selective evaluation can be faked, but it's not part of their syntax. Lisp can be procedural, functional, or a primitive type of object-oriented. Lisp source code is equivalent to data that Lisp programs operate on (i.e. source code is made up of Lisp lists); this makes Lisp a sort of mind-bending meta-language over a meta-language. Of course that's not at all useful in practice (yes, it makes it stupidly easy to write a Lisp interpreter in Lisp but it's not much harder to write one in a better language), and it comes with the crippling downside that Lisp source code is extremely hard to read. What I'm saying is that I agree that Lisp has a laundry list of features, some of which no other programming language has, and which do not all appear together in any other language. This may sound like several points in favor of Lisp, until you realize that few, if any, of those features are at all useful or productivity-enhancing.
So why are the fields of artificial intelligence and cognitive modeling so enamored with Lisp? Certainly not because Lisp is an easy language to learn. Nor, in my opinion, does it have any features or peculiarities that make it particularly well-suited to those areas. The only option left, I think, is that code in those areas started being written back in the days when Lisp was in vogue, what with its primitive object-orientedness in the face of the rigid sequentiality of languages like ALGOL and Fortran. Back then, computing was still an endeavor restricted to academia — commercial software was not being written in earnest. This is why commercial software for the mass market didn't become similarly locked in to Lisp by tradition. Nowadays, I really believe there's no particular reason to write code for AI research or cognitive modeling in Lisp. Any reason there originally was (Lisp is the best language available, Lisp does abstraction, etc.) has been completely obsoleted. It's the status quo — if you're writing AI or modeling code, you do it in Lisp because that's just how it's done. And, of course, there's so much legacy code in Lisp that it's kind of foolish to try moving it all to another language, and of course code in a new language would be unable to interface with older Lisp code. The fact that there's such a large AI and modeling code base in Lisp means that it's pretty much mandatory for a researcher in either area to learn Lisp — in a sort of throwback to the old days, if you've got to choose one language to learn, make it Lisp. And because the situation just propagates itself thus, there's no reason for a researcher to learn any other language.
So there you have it, my cogent argument as to why Lisp, an outdated and, by many standards, inferior language continues to be used in some areas and promoted for rather baffling reasons. I say cogent to distinguish it from any irate diatribes I may have posted or may post, probably centering around the fact that Lisp syntax contains way, way, way too many parentheses.
Labels: geeking, programming
