If Lisp is the perfect language, why are there so many?

Question

Possible Duplicate:
Why is the Lisp community so fragmented?

Despite the snarky tone, I'm actually looking for a serious answer.

I know the textbook response: Lisp is a model for computation, not a "language" per se. Still, why exactly are there so many different dialects of Lisp?

Presumably it isn't because of surface syntax issues or crucial missing features, the way it is with so many other languages. But if not that, then what?

Do they interpret that model of computation in slightly different ways? Are they pursuing different simplicity versus efficiency tradeoffs? Is it because of limitations in different compiler/interpreter codebases? Or something else entirely that non-Lispers like myself can't even imagine?

I suppose the followup question would be: if the differences matter, which is the best modern Lisp for real-world usage?

Thanks, Dr. Ernie

Answer 1

because it's a mudball, it gets picked up and shaped but still remains what it was

Answer 2

Common Lisp is a standard, but there are many other implementations. It shares that trait with many other languages like C, C++, Fortran, Ada, etc. If you look around, you will find that there are many implementations of all these languages, with slightly different flags, options, and support for the corner cases.

Many other languages that are common today were not standards (at least to begin with) and included one conical implementation/compiler/interpreter. I am thinking of languages like Perl, Python, Java, .NET, Ruby, etc. There may be some off shoots of these languages, and ports to new platforms...but overall the syntax and usage of the language is always referenced to the one true implementation.

I use the GNU CLISP for my work...I chose it because it is free, available for the platforms I am interested in, reasonably well documented, and appears to be robust, mature, and complete (at least in terms of the ANSI Lisp Standard). You may have very different requirements for your Lisp environment, and that may lead you to a different choice for your implementation.

Answer 3

There are a number of reasons for the many dialects of Lisp, some historical, some technical, and some mostly psychological.

Historical: By classical standards, Lisp was fairly slow and used lots of memory. Quite a few people have devised various techniques (or corruptions, if you don't like them) to try to make it more practical. This was especially true when Lisp machines were being built -- the hardware was devised specifically to run Lisp, and at the same time, the Lisp they ran was devised (revised?) specifically to run on that hardware and to take full advantage of its capabilities.

Technical: Some decisions that have been made at times in Lisp were questionable (to put it nicely). For example, all modern Lisps uses lexical scoping, but quite a few early ones used dynamic scoping. Some Scheme users don't think much of the non-hygienic macros in most other Lisp dialects.

Psychological: Lisp is so simple that many people have felt qualified to write their own implementations. Many Lisp programmers are also fond of experimentation and pursuing perfection, so many of those implementations included the implementors idea of improvements of various (usually incompatible) kinds. Nobody was coordinating efforts so many of those extensions/changes were incompatible with each other in various ways, so each became a (more or less) distinct dialect. Some of this was probably avoidable, but some of it wasn't -- just for example, two people might see a particular feature as flawed. One would work at improving it to something he found more acceptable, while another removed it completely, and either considered that an improvement in itself, or possibly devised something completely different to replace it.

Poor communication also often played a role. Somebody at (say) MIT might go somewhere on sabbatical, and take along a tape of some Lisp implementation, which would start to be used wherever they went. That would often (quite unintentionally) fork the implementation, as the two schools did work independently in parallel.