This is a personal rant about CommonLisp, LispSucks or WhyWeHateLisp and RichardGabriel's WorseIsBetter.

Richard Gabriel, in his famous WorseIsBetter paper, argues that Lisp (Common Lisp, specifically) is better than C. Richard mentions briefly two different philosophies on design and thereafter it is more-or-less assumed that Lisp is inherently better than CeeLanguage.

This rant is not about the two philosophies or the degree that each camp actually believed or followed such philosophies (or if such philosophies actually did exist). This rant is about why CommonLisp actually is worse than CeeLanguage (among others), but first let me lay to rest this notion that there actually was an MIT philosophy to begin with.

Richard starts out by stating that "the design must be simple." Anyone who knows the Lisp world at all can tell you that SchemeLanguage and DylanLanguage are much simpler than CommonLisp. Both in terms of interface and implementation. It is also quite obvious that the Common Lisp community at large does not believe in or follow this part of the MIT philosophy. By Richard's own admission, if there is a better design, the MIT people have no choice but to follow it due to their philosophy. Therefore, CommonLisp should, in theory, have been disposed of many years prior. It wasn't, obviously.

Just to make sure this idea of dual philosophies is good and dead, Richard makes another point that "the design must not be inconsistent". One needs only to take a look at the naming of CommonLisp predicates to find numerous inconsistencies. It is important to keep in mind how trivial a syntactic name change is compared to a semantical change. Yet CommonLisp kept these inconsistencies due to reasons such as Lisp Machine vendor influence. That hardly seems like the caricature of "better" that Richard paints. In fairness, he does mention Scheme as part of the MIT philosophy, but only in brief. By Richard's fourth point, "the design must cover as many important situations as is practical", it is unclear whether Scheme actually even fits this caricature.

If we get carried away, we soon follow these caricatures blindly leading us to believe that C actually is worse. This is not so.

First, CeeLanguage works. It works wonderfully. Today. Not twenty years prior when LispMachine''''''s ruled the earth. Infact, C was working wonderfully back then too. The fact that C coexists with other (new and "better") languages is a testament to its solid design.

There are many reasons that CeeLanguage works. One big reason is that C has completely nailed the library issue, in terms of ease of use. All a programmer has to do is include a few "header" or "include" files and call it a day. Satisfied knowing that the compiler and linker will, for the most part, take care of the rest.  

There are, of course, issues such as library installation and DllHell. This is where CeeLanguage design really shines. Each part of what one thinks of when "programming in C" is delegated to certain facilities that are completely separate from the core language of C itself. For file I/O and many other tasks, there is POSIX. Library installation is handled at the operating system level. It simply is not a language issue at all.

There is an actual language to C that does not include library code such as strlen(), etc. Core semantics are easily identifiable and are not tangled in the least bit (with the exception of threads and setjmp()) with what is considered the language itself. In Common Lisp, on the other hand, it is hard to identify any recognizable theme of a language. It has parts of ZetaLisp, FranzLisp and whatever else that was forced down the throat by vendors prepared to walk out.  

CommonLisp is very much a Lisp Machine emulator. It dictates too much semantically on the implementation's side and too much stylistically on the user's side, but never satisfies either group to a decent degree. It seems there is only satisfaction in certain areas that were more-or-less one vendor's idea. Not too many people have complaints about CLOS (other than maybe the "methods as part of a class" vs multi-dispatch).  CLOS was mostly Xerox.

The entire idea of packages (and later the idea of having "modules" in Scheme) is overwhelmingly complex and is a complete kludge for proper namespace management (which should have been delegated to the compiler in the first place).

C gives the programmer upfront efficiency from even the dumbest compilers. Common Lisp is still waiting to this very day for their SufficientlySmartCompiler. It would be wrong to place the blame on GarbageCollection. It is much more than that. This is not to say that certain aspects of CL can not be made efficient, either. Rather, it is to prove why C is "better" and has dominated the programming language scene.

With such complexity in actually creating library code, the strong ties to Lisp Machines, and the lack of nearly guaranteed efficiency from mastering such a complex beast as Common Lisp, is there any wonder why it has been such a failure?

Now I will conclude with a rant about CommonLisp and the future of Lisp.

Common Lisp is at a stand-still. It is important to realize that it will never move again, unlike C which has had an update in 1999 (or even Scheme, in 1998).

Nearly all vendors that I know of are a former shell of what they were in 1988. Even Borland, who has taken the worst beating of all from the biggest bully of all, is stronger than the largest Common Lisp vendor, who had no bully even in the market!

"Common" Lisp is not so "Common" today. I would put good money down that ELisp (EmacsLisp) is more widely used than Scheme, Common Lisp, and Dylan ''combined''.

The standardization process will never happen again for CommonLisp. It costs too much money, is too difficult to get everyone to agree, and is much too painful for some to even watch. The "features" that Common Lisp inherited from the many vendors will remain "features" because new users will continually use these "features".  Thus, the cycle of garbage will continue until Common Lisp is a footnote in the history of computer languages.

There is a definite rise in interest in Lisp today. By that, I mean the family and not just Common Lisp. I fear that even the marketing power of Paul Graham is not enough to save this sinking ship, though. Dylan has died in a mere handful of years, R6RS will never get done (or worse, continue the divergence from the Scheme way that started with the transition from R4RS to R5RS), and Common Lisp will continue to decay at a steady rate. Where is my usable Lisp? Something that just ''works''.
----
If AppleComputer had stuck with DylanLanguage, then we would probably have a fairly mainstream very lisp-like language.  Dylan remains my favorite programming language, but it's good as dead except for the GwydionDylan guys and the Functional Objects open sourced stack.