Lisp: Good news, bad news, how to win big analysis
Back in 1991, when the article was originally published, Lisp had been doing great as a programming language; it was about to become a standard, it was achieving excellent performance, had good environments, amongst other things. However, its success didn’t depend on how good the language was, but on how its community took advantage of that, and they were failing to do as well as they could’ve.
Lisp’s successes
Lisp had been in better shape than it had ever been in past years, and it was due to various aspects.
One of the major successes for Lisp, is that there was a standard version — Common Lisp. Although it wasn’t considered the best Lisp there was, it was the only version of Lisp that was ready for standarisation. This didn’t mean that another Lisp could become standarised later, but Common Lisp was the one that people had a common interest for.
There was also performance. Common Lisp performed well, and had modern compiler technology to its advantage, compared to older versions of Lisp that used primitive techniques. Back then, anyone who used Common Lisp on pretty much any computer available could expect a better experience and better performance than what could be obtained in the past on single-user PDP-10’s or Lisp machines from the mid 80’s. Incremental compilation, data inspectors, window-based debugging and structure editors were some of the features originated in the Lisp world.
Lisp was also able to coexist with C, Pascal, Fortran, and many other languages. These languages could be invoked from Lisp, and they could re-invoke Lisp. These interfaces enabled the programmer to pass data, manipulate it and load programs from Lisp to foreign code, and from foreign code back to Lisp.
Object-oriented programming was also a strong feature on Lisp. It had the most powerful, comprehensive, and pervasively object-oriented extensions when you compared it to any other language. You could inherit from multiple classes, it had generic functions, metaclasses, method combination, etc.
Lisp’s failures
As good as Lisp may have seemed, there was a conflict and rising tension between two philosophies that eventually caused Lisp to fail. The Right Thing and Worse Is Better philosophies proved to be a key problem for Lisp.
As programmers, we are supposed to aim for a program that aims for the following 4 key aspects:
Simplicity — The design must be simple, both in implementation and interface. It’s more important for the interface to be simple than the implementation.
Correctness — The design must be correct in all aspects.
Consistency — The design must avoid inconsistency at all costs. A design is allowed to be less simple and/or less complete if it’s for the sake of avoiding inconsistency. Both consistency and correctness are equally important.
Completeness — The design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to reduce completeness.
That’s what we should be aiming for. However, the rise of Worse Is Better changed the terms ever so slightly:
Simplicity — The design must be simple. It is more important for implementation to be simple than the interface. This is the most important aspect of design.
Correctness — The design must be correct in all observable aspects. It is better to be simple than to be correct.
Consistency — The design must not be overly inconsistent. Consistency can be sacrificed if it’s for the sake of simplicity, but it is better to drop those parts of the design that deal with less common circumstances than to introduce implementational complexity or inconsistency.
Completeness — The design must cover as many important situations as is practical. All reasonably expected cases should be covered. This aspect can be sacrificed in favour of any other quality, mostly if it seems to put the implementation simplicity in danger. Consistency can be sacrificed to achieve completeness if this means that simplicity is retained. Consistency of interface is especially worthless.
Early Unix and C are examples of this school of design. The worse is better philosophy has better survival characteristics than the right thing philosophy for obvious reasons.
Good Lisp programming was hard. Although its enthusiasts believe that programming with Lisp is easy, the fact was that it was only true up to a point. The fact is that, although programming with C was always difficult, that made it really difficult to write a program that performed poorly. That wasn’t the case with Lisp. The ease of use also made it easier to write programs that performed very poorly.
The fact was also that non-lisp environments were also catching up. C environments were becoming really good, since they were imitating Lisp environments. They were adopting features that gave Lisp an advantage, which meant that Lisp would either have to become better at performing these tasks, or come up with more useful features. Lisp was also falling behind, since the environments had several failures that were simply unforgivable. Although they were window-based, they weren’t well integrated. They weren’t persistent. They weren’t multi-lingual even when foreign interfaces were available, etc.
If you want to read more on the subject of worse is better, here’s the link to the original article: https://www.dreamsongs.com/WIB.htm
