I guess it depends on what you mean by "very good" and how big that "+" is, but weren't there at least two? For people with access to a Unix box (usually via universities, companies, or a shell account), CMUCL was available, typically on SPARC/Solaris, since the mid-80s sometime. And for people running home microcomputers, clisp was freeware on the Atari ST from the late '80s, and released as GPL in 1993, with ports to DOS, Amiga, and Linux.

Emacs LISP (OK, a limited dialect) was available and so was CMUCL (full implementation), which I believe was used for teaching in 1992 when I first got in contact with LISP at our uni ...

Also, back then (80's and 90's) most people still paid an arm and a leg for C, Modula and Pascal on their platforms, so that can't have been an issue. My take is that LISP implementations were too slow to justify their use for most people over faster compiled languages. Whether you paid for the language or not, you expected to be able to get the most out of your hardware.

Meanwhile C/C++, Pascal and Java were all accessible and cheap if not free...

Java and C++ had capable, even enterprise quality free compilers at a time when Common Lisp environments were typically either hideously expensive or poorly supported or both.

You could grab Sun's JDK for free, or GCC, or (later) Visual Studio Express at a time when the best options for Common Lisp were thousands of dollars per seat, or barely working on x86 (CMUCL didn't have x86 support in any capacity until after 96, and by then Java was out).

Personally, I loved lisp in the 90s, but it was just so much easier to get my hands on C and Java, and libraries to go with them. Java, C and C++ were actually available on DOS and Windows. Even today, Windows support among lisps is terrible!

Edit: I miss Turbo C, but had there been a Turbo Lisp, priced affordably and on the shelf at radio shack? We'd all be programming in lisp.

Also, 1, I am not a GC basher. 2. I was wondering why Lisp didn't take over most of the world 15+ years ago. Overhead was more expensive then. (And small embedded systems will always have too little RAM.)

Common Lisp was designed for interpretation and compilation from day one. The first implementations from 1984/85 had already compilers.

> Common Lisp, for example, is probably more dynamic than Python

Some parts are more dynamic than Python, some not. For example everything that uses CLOS+MOP is probably more dynamic. Also some stuff one can do when using a Lisp interpreter may be more dynamic. CL is more static, where one uses non-extensible functions, type declarations, static compilation, inlining, ... The parts where a CL compiler achieves good runtime speed may not be very 'dynamic' anymore.

the currently most popular Common Lisp implementation is based around an optimizing native code compiler. That compiler has its roots in the early 80s.

See http://sbcl.org .

It's far from being 'interpreted'.

> Around 2004... There were two free, open source Lisps available (CMUCL, CLISP) and both were rather unloved and clunky at best.

SBCL and ECL existed and were quite usable.

The documentation was as you say, another story. There was the HyperSpec, copies of CLtL, and a number of out-of-print or hard to find books that described some kind of Lisp. It was hard to be a tyro without a guide.

It's a dead horse and people can't help but beat on it as they pass by.

I wouldn't call it a dinosaur language either. The specification of Lisp that we call, "Common Lisp," was ratified by ANSI in 1994 -- putting it almost neatly between ANSI C (1989) and ANSI C++ (1998). Common Lisp just has a longer history than those two languages so it tends to get flack from the young'uns and ignoramus' for being, "old and crufty."

It's a small community but there are plenty of libraries, tools, and compilers under active development.

I wouldn't say Lisp "didn't stick"; it's been in continuous use for half a century. Writing Lisp code would be anything but "sudden".

Of course we can say the same thing about COBOL, but that seems mostly due to the inertia of legacy applications; its target demographic of business applications now favours languages like Java.

On the other hand, new projects are being written in Lisps, and it's still spawning new languages (e.g. Common Lisp, Clojure, Kernel, all the Schemes and their descendents, etc.). This seems to indicate that people want to use/extend Lisp, rather than having to use it (although there are certainly legacy Lisp applications out there, which may or may not be horrendous to maintain).

Also, as Alan Kay points out, Lisps frequently "eat their children": someone invents a "better language", then someone else figures out a way to do the same thing as a library in an existing Lisp. This means that very old dialects/implementations may be perfectly capable of using paradigms/fads/etc. which were only invented/popularised much later, e.g CLOS for OOP or call/cc, shift/reset, etc. for coroutines/async/promises/etc.

In contrast, those languages which truly "didn't stick" are seldom heard of, outside the "inspired by" sections on Wikipedia. Many of are uninteresting, such as machine- or company-specific dialects, which died along with their hardware/sponsor. Others can be very informative, especially regarding "flavours of the month" and "paradigm shifts":

- Simula (arguably the origin of OOP as found in C++, Java, C#, etc.)

- ALGOL (the archetype of lexically-scoped procedural languages, like Pascal, C, Go, etc.). Actually, I still see "idealised Algol" discussed in cutting-edge programming language research, so maybe it still has some life!

- SNOBOL, which enjoyed great success in the world of string manipulation, and now seems to be completely replaced by awk/sed/perl/tcl/etc.

- MUMPS, which integrated a key/value database into the language. Still used, but seems to be for legacy reasons like COBOL (e.g. see http://thedailywtf.com/articles/A_Case_of_the_MUMPS )

- Refal, which relies on pattern-matching for evaluation (now widespread in the MLs (Standard ML, OCaml, F#, Coq, etc.) and Haskell-likes (Haskell, Clean, Miranda, Curry, Agda, Idris, etc.). Also notable for using supercompilation.

- ABC, the prototypical 'scripting language', and a direct influence on Python.

- FP, which emphasised higher-order programming.

- Joy, a pure functional language based on stacks and composition, rather than lambda calculus.

- REXX, widely used as a "glue" language; I think AppleScript has comparable use-cases these days (I don't know, I've never used an Apple OS). Seems to be supplanted by shells and embedded scripting languages (e.g. Python, Lua, JS)

- Self, famous for prototypical inheritance and the origin of the "morphic" GUI.

- Dylan, effectively a Lisp without the s-expressions. Created by Apple, but quickly abandoned.

- Prolog, a logic language based on unification. Still has some users, but didn't take over the world as some thought it would (e.g. the whole "fifth generation" hype in the 80s).

it was never a goal in the Lisp community to develop a single unified or leading implementation. This has nothing to do with 'free software' or not.

First 'Lisp' can't bet. It's a programming language. As a community it is extremely diverse.

Let's get the history of Common Lisp right. Common Lisp was created to unite the successors of Maclisp (and related languages) and to make it feasible to create and deploy applications written in it. During the development of Common Lisp from 1982 on it was immediately implemented on all kinds of machines: especially on Unix, Windows and Macs. LUCID CL was a commercial system for Unix, LispWorks started on Unix, moved to Windows and the Macs, Allegro CL was on Unix and moved to Windows and later to the Mac. Golden CL was on Windows. Exper CL on the Mac. Macintosh Common Lisp on the Mac. KCL/AKCL/... on C. CLISP in C. Plus tons more.

When I worked in an AI Lab in the early 90s, developers were using: Macintosh Common Lisp on Macs and Allegro CL on SPARC/Solaris (used in 'planning and configuration'). We had a LispWorks license for SPARC/Solaris for an image processing project. Golden CL on Compaq/Windows. Lucid CL was used on SPARC/Solaris for a commercial project. Lisp Machines were not used anymore.

It just happened that at the end of the 80s / beginning of the 90s the development of applications which were typically developed in Lisp moved to C++. Reason: better deployment options on machines of that time and 'momentum'. Some then even moved to Java later. Few moved back when Common Lisp came back during the early 20xx years.

Common Lisp lacks 'standard lacks facilities' - just like most languages. Java has Swing, but it's not really successful. Then came SWT. ...

It's not that the Common Lisp community did not try to develop a GUI library standard. During the standardization process there were efforts in that direction. For example 'Common Windows'. But the funding died out and when new platforms appeared (Cocoa, GTK, ...) Common Lisp was out of fashion. The result is that the best GUI toolkits for Common Lisp are commercial: CAPI from LispWorks and Allegro's GUI Toolkit. CAPI runs natively on top of Windows, Cocoa and GTK+.

Common Lisp implementors support the development of Windows applications usually through the commercial offerings: Allegro CL and LispWorks. With some minor alternatives. It's just that these tools are expensive - as expensive as comparable options for other languages.

But the great thing about Lisps is that they can't get stuck in the past.

For example, if, say, Python didn't have decorators and you wanted to add them in, you'd have to present the idea in a PEP, get approval from Guido, write some code, et cetera. In Common Lisp, you just write some reader macros and that's it[1]. If Python stopped being maintained, it would lag behind other languages, but the fact that the Common Lisp spec hasn't been updated since 1996 doesn't make it any less modern.

A more relevant example: Lisp doesn't have hash table literals, which every "modern" language these days has, but those can also be added, trivially in less than fifty lines[2] of CL code, and suddenly Common Lisp is modern again.

[1]: https://github.com/arielnetworks/cl-annot

[2]: http://frank.kank.net/essays/hash.html

Imagine the standard, cross-platform GUI you'd get in 1994 (the time of the ANSI spec approval).

Hm. If we do this, then C++ is merely one 'capstone' on the history of Algol development, which is about as old as Lisp is.

My personal hunch is that lisp was just too expensive when most industry took off. In near every way. C compilers being basically free is a ridiculous advantage. Yes, there are free lisp implementations today. However, early mover advantage is working against them, now.

The 'archaic' elements are due to backwarts compatibility with Lisp. You get that raw core of Lisp from the 60s: s-expressions, cons cells, LAMBDA, LIST, CONS, CAR, CDR, APPEND, COND, EVAL, PRINT, PROG, READ, macros, dynamic binding, ... all these (and more) are still in Common Lisp.

Common Lisp is an improved Lisp dialect, not a fully new language. A goal was to relatively easily port some existing software which was written in the years from 1958-1984 to Common Lisp. CL appeared in a documented form in 1984 with CLtL. Thus some code that ran in Common Lisp was a port of code written starting in the 60s, like Macsyma. People did not want to throw away hundred thousands lines of code and they wanted to use the newer language, because it was available, slightly better than the old one and was supported on more machine types.

This language was mostly developed by five people: Scott Fahlman, Guy Steele, David Moon, Daniel Weinreb, and Richard P. Gabriel.

> and trying to put something together to unite the many different lisp implementations at the time

Common Lisp is specifically a successor to Maclisp, mostly based on Lisp Machine Lisp (another Maclisp successor), by simplifying/generalizing LML. It's even not directly compatible with LML. It's much less compatible with other Lisp dialects of the time: Interlisp, Scheme, IBM's Lisp, Standard Lisp, or even Scheme or Logo.

After the initial design of Common Lisp was done, an effort was started to standardize the language: improve it and add a bunch of important features like error handling and object-oriented programming.

Error handling was then based on the Symbolics 'New Error System' and the object-system CLOS was a new design based on Flavors and LOOPs - two earlier Lisp extensions.

The most committee like design was actually CLOS. But even that was driven by only six people, lots of community support and a portable reference implementation (PCL).

Arguably, CLOS is one of the greater designs in the Lisp language space.

The third part then are implementation extensions, which got especially important, when the standards effort went out of steam/funding/interest...: concurrency, unicode support, foreign-function interfaces, standard libs, ...

The design advantage Common Lisp has over Scheme is that it started as a larger integrated language. This makes features know of each other and the language is designed to use and support them.

Scheme has often this feeling of a very small core language, even a too small core language, and a lot of stuff bolted on top. The result is that 'practical' implementations (practical here means implementations which are used to write software and not so much as a teaching language/implementations) often reach the size of Common Lisp and one of its implementations AND all of them are diverging in some basic ways (Chez, Chicken, Racket, Guile, ...).

Take for example the object system. Since CLOS was added to Common Lisp no one bothered to propose a replacement for it in Common Lisp. Thus every implementation, small and large, is using it.

> but the Chez Scheme migration should help out Racket a bit

If I would want to use Scheme, I'd use Chez Scheme directly. It's a great implementation of Scheme. In provides what many Common Lisp systems (incl. SBCL) also offer: an optimizing native code AOT compiler. Chez already has what Racket now gets: an improved implementation mostly written in itself.

1. Lisp is a single language, with one fixed set of trade-offs, rather than a large family.

2. Lisp has been around for a long time, and isn't developed any more and has only historic significance. People who work with Lisp are essentially retro-computing hobbyists, not keeping up with what is going on.

With regard to (1) Lisp is a fairly large family, and the members are different from each other. The strength and weaknesses of, say, Gauche Scheme are not the same as those of Armed Bear Common Lisp (to pick a random pair).

There are Lisps that give you general purpose programming on Unix or Windows: multiple programming paradigms and access to the entire platform. Anything the system is capable of doing, you can do it through Lisp.

With regard to (2), there are certainly some people who are into retro-computing in regard to Lisp. For instance, a few people have revived the historic Interlisp iplementation from the 1970. They have it running with its windowing system and all. There is an active trading market for old Lisp hardware like Lisp machines of various kinds. Sure.

By and large though, people who are working with Lisp of any kind for real work are using something contemporary that is being developed. Just like people working with C (also an old language by now) are likely on a recent Clang or GCC, and not Borland Turbo C 2.0 for MS-DOS. Lisp people move on from old Lisp implementation, like they do from old C or Python implementations.

You're dismissing the existence of new Lisp dialects, and of continuing development of existing older implementations.

You're also dismissing the possibility that contemporary Lisp programmers might actually know Python, Go, C# and so on. Including ones who work on maintaining implementations.

People who knows those other things and some kind of Lisp or two probably make better informed decision in regard to whether or not they use Lisp, that those who don't know any Lisp.