On Scheme

Thoughts on Scheme and teaching Scheme

In Defense of Change

Posted by Peter on April 21, 2006

Recently there has been a burst of criticisms concerning Common Lisp. If you don’t know what I am talking about, or simply want to catch up on the current discussion before you read the rest of this piece you should visit: Steve Yegge’s blog, the usenet response, a usenet debate on CL suckage, and a usenet proposal for improving CL.

Although they have been accused of hating Lisp, my impression is that the majority of these critics love Lisp, and simply want to see it become better. For those of you who got lost in the flames let me provide a quick summary of the major complaints: 1- macros: there is no hygienic defmacro, but define-syntax may be too cumbersome for some, and also it is hard to hook some aspects of the source with macros. 2- CLOS: CLOS is becoming dated, looks too much like a hack, and is too hard to use. The object system needs to be rewritten, possibly from scratch. 3- There is no type system outside of run-time checking. 4- The Lisp community has become too fragmented, even Common Lisp implementations tend to provide features that makes them incompatible with each other. 5- Common Lisp has stagnated for too many years, and there is no way to implement changes that will be adopted outside of a single implementation, which ensures that no serious improvements are made.

In my opinion these are valid criticisms and, although they are directed primarily at Common Lisp, Scheme is not without its own flaws. I don’t believe that accepting these criticisms as valid implies that one should drop Lisp, even with its flaws I think that Lisp is still the best language, it just could become better.

However I am not writing this piece to discuss the criticisms or to propose solutions, what I want to address here is the response of the community to them, which I found appalling. Some people’s responses were scarily reminiscent of religious authorities trying to cast out heretics, which is not an appropriate attitude for a computer scientist. As scientists we should always be looking to improve our tools and methods, and this means trying new things to find out what changes constitute an improvement.

Let me discuss what makes some responses I have heard especially ridiculous.

The difficulty argument:
We should leave confusing / ill designed feature untouched because it makes Lisp harder, and thus keeps out the riff-raff. This is a flawed argument because a large volume of users is more important than a few brilliant users. Even mediocre programmers can write useful libraries / promote the language. Libraries especially make a language attractive to even more programmers, and for use in commercial applications. Basically if you want to make a living using Lisp then you should hope more programmers use Lisp, even if they aren’t as “133t” as you.

The fear of change argument:
We shouldn’t change feature X (often CLOS) because it is used so widely that changing it would force me to learn new things / update my code. This is a flawed argument because other languages (with supposedly dumber programmers) are able to change themselves without problems. If you depend on a removed feature you can always use an older compiler for the code, for example Visual Basic 6 is still used to build some older applications that aren’t compatible with Visual Basic .Net.

The perfection argument:
Feature X is perfect they way it is. This is unbelievable because perfection tends not to be humanly possible; we simply try to approximate it with a greater and greater degree of accuracy. It is possible that a change could be worse than the current way of doing things, but once we are open to the idea of change there is nothing stopping us from changing it again until we revert it to the original state or really do find something better.

The “it could be worse argument”
Sure Lisp has problems, but it is better than languages X, Y, Z and that is good enough for me. I admit that Lisp is better now, but you can’t really be sure that will always be the case. If Lisp doesn’t move forwards than we can rest assured that something better than Lisp will be invented eventually.

The diversity argument
Fragmentation gives you options. Sure it does, you just can’t have them all at once. If you want feature Y in implementation A you have to give up Z in implementation B. Experimenting with variants is important of course, but that is why people write toy versions of languages, to try out new ideas. Ideally the best features are then incorporated into the next version of the standard implementation(s). The problem with Common Lisp is that such features don’t make their way to the spec., and it looks like they never will. Also, confusing the versioning of a language with Common Lisp’s fragmentation is so ridiculous that I am not even going to address it.

The personal attack argument:
You don’t really use Common Lisp! Go out and code instead of bitching! God forbid we not be content with the status quo!

What should be done?

So what should you do if you think Lisp could use some fixing? Go out and fix it. Go write a toy version, it doesn’t have to be fast or efficient. However if you can use it to demonstrate something cool that fixes a problem people will either help you make it faster and smaller, or your feature will be adopted by a more professional implementation. Do this enough and you just might end up with a new popular Lisp dialect.

About these ads

2 Responses to “In Defense of Change”

  1. Thank you for posting this. I completely agree that these religious flame wars that invariably use mounds of logical fallacies do no service to the computer science community. It still surprises me that Lisp has so many true believers given its staying power. Does the Lisp community really feel so insecure in the second oldest programming language that they must defend it in these ludicrous ways?

    Personally, I’m hoping that all the recent attention given to Lisp’s warts will help spur people to do exactly what you described, namely fix them. *smile* Along those lines, have you checked out the Qi Programming Language from Lambda Associates? It solves the Lisp type problem once and for all by defining types in First Order Logic. It also uses pattern matching a la Haskell, ML, and Prolog. It has guards like Haskell as well. And it is built entirely on Common Lisp. As a short example of the expressive power of Qi’s type system, I have created a Prime type in Qi that allows for a compile time proof of primeness. No more waiting for runtime to ensure that you have a prime! *smile*

    Hope to hear more about what you think! Thanks for the post.

  2. Eric said

    Very well put post and I believe that you can substitute any programming language into your responses to each argument. I personally have not tried Lisp but have been wanting to try it out for long time now, just have not been able to block out some time for it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: