I've been a Lisp hacker for years -- Symbolics Lisp Machine in my bedroom, coded in at least a half dozen different Lisp dialects -- but I ended up using Smalltalk for my startup. Treating Lisp's "rehabilitation" as a mere branding exercise shows just how screwed the Lisp community still is, and is symptomatic of the underlying issue. (By "Lisp", I mostly refer to Common Lisp.)

Lisp's problem is a meta-problem. The community is actively resistant to advancement, change, and evolution in the language. Attempts to modify (or even clarify) aspects of the Common Lisp standard are tedious exercises in futility, but the standardisation straitjacket is still seen as a good thing. A bit strangely, this resistance to change existing standards is accompanied by a slowness to standardise (even informally) anything that isn't already. The end result is that there's still no reliably portable way to write networking code in CL.

And this is why Lisp is unpopular.

The stasis is sad and ironic, given Lisp's hackerdom beginnings. Rather than wonder why, in 2009, so few are using Lisp, we should be amazed that the language is still pretty cool two decades after the innovation stopped.

I hope the Clojure guys change things. They seem to have the right approach.

Footnote: I was going to be a member of the CLRFI group (roughly equivalent to PEP or SRFI) that got some interest at ILC 2005, and which was going to try to create some sort of forward momentum in the community. It frizzled out, of course, and now http://clrfi.alu.org/ appears to redirect to the ALU homepage.

In many ways, Clojure seems like a deliberate response to each of the common complaints against Lisp.

    Lisp is old and moldy. It must be primitive by today's standards.

    The exciting languages to learn now are Python, Ruby, Groovy, etc.

    Lisp is only for artificial intelligence.

    Lisp is interpreted and slow.
    Lisp programs page heavily, so they're even slower.

    The parentheses look weird and hard to manage.

    Lisp uses prefix notation for things that every other popular language
    does with infix notation, which is just very weird. (And it leads to
    more parentheses.)

    Lisp is too big.
    Lisp is too hard to learn.

    Lisp is all about lists and recursion; that's all you do with it.

    I don't know which implementation to use.

    It isn't "batteries included" (that is, it's not easy to get set up with all the tools and libraries you need).

    I don't like Emacs, and you can't use Lisp without Emacs.

    Lisp isn't useful for my career; few potential employers want it.

Even the clojure contrib jar is not included by default and has to be downloaded separately and then clojure needs to be launched with extra command line arguments to setup the classpath properly (or you need to fiddle with the classpath from within clojure), the same goes for any Java library that you want to use.

Even by itself, that is better than most Lisps out there, if not enough to make a Pythonista happy. The problem with this stuff is usually the painful verbosity of Java necessary to use it, but you can wrap away that pain very quickly with Clojure.

I do take the point about needing to fiddle with the classpath for any other Java code you want to use. But for me the Java classpath system holds up better than most other software deployment mechanisms. Usually, you just download a jar file, drop it on your classpath, and it just works. I think jar files are an unappreciated success story of the Java ecosystem. Clojure has functions to easily add jars to the classpath at runtime, which is even better, but I find it does not always work seamlessly for me.

The only response that wasn't along those lines (or the old "Lisp is just too awesome for lame modern coders" shtick) was Ian Eslick's long one "A Coherent Portal into the Lisp World"; he actually seemed aware of why it was hard for new folks to get into Lisp and had suggestions about direction.

I'm getting ready to start a new project with a significant GUI forms component. I wanted to go with Clojure, but it still seems a little rough around the edges. So I'm leaning towards Visualworks Smalltalk, in part because it seems like a great language to prototype in and partly because the OOP aspect fits so well with GUIs.

I'm curious: did you consider Clojure? Would you mind elaborating on why you went with Smalltalk? given the number of Lispers on this site, the answer might be of broad interest.

Doesn't VW have a "pay us x % of your revenue forever" license (http://www.cincomsmalltalk.com/userblogs/cincom/blogView?con...)?

I am curious as to why any startup would want to accept these terms.

My app will work best as a thick client, but I still need a website to sell it.

The code snippet from CLSQL looks horrendous:

  ;; select the user with ID 1 and set his username column to joe
  (let ((user (first (select 'user :where [= [id] 1] :flatp t :refresh t))))
    (setf (username user) "joe")
    (update-records-from-instance user))

  User.find(1).update_attribute(:username, "joe")

  (update-attribute (find *User* 1) 'username "joe")

  (rec-set-prop! userid 'username "joe")
  (store-rec! userid)

http://common-lisp.net/project/elephant/

Thus the situation is inescapable. You need tons of libraries to be productive. You need tons of programmers to write these libraries. You need an easy learning curve and appealing features to get these programmers. The bottom line is that you need the bad coders as well.

As a beginner, I can safely say that it took a while before I finally got reasonably productive in Lisp. I still consider it 'the best' programming language. But the learning curve is much steeper than Python.

Lisp will get nowhere without all the bad programmers. This may sound cynical, but the reason is that academically minded programmers won't spend time writing things like a download library for youtube videos, which many people find useful. These programmers are now all over Python.

So why is Lisp difficult to learn? The most severe in my opinion is assignment. People find it intuitive to make temporary variables and store intermediate results in these. This is done by 'let' in CL, but if the previous style of programming is assumed, 'let' is clumsy and inconvenient to use.

Another achilles heal I would like to mention is the lack of an editor with propper auto-completion. Yes, slime does this, but using emacs is too geeky for many programmers (remember you need these people) and this creates an additional stumbling block.

Yet another problem is the CL websites. Remember that many people are in a hurry. The Python website is ripe with snippets that lets you do stuff fast without understanding much. In contrst, CL gives you some of the most monotone autogenerated documentation sites I've ever seen. Again, fine for people who already know Lisp, tedious for people that want to try stuff out as beginners.

Faced with these realities I don't blame anyone who just want to get things done and run with Python. Unfortunately.

Great egalitarian point: it's not just karma, but that everyone has a unique point of view, with something to offer. Rejecting some segments of the population as inferior seems destined to fail, similar to (excuse my Godwin) rejecting people like Oppenheimer.

And when you "just want to get things done", aren't we all "bad coders"?

Clojure solves this problem by going all the way to the opposite extreme. "No assignment for you." Clojure data structures are immutable, and if you really want to do assignment, you need to explicitly use a ref/var/atom, which means you are going to figure out a way to write your program without assignment if at all possible. Clojure, of course, is designed around functional programming that has many idioms to make assignment-less programming the natural way to do things.

I guess what this means is that Clojure can appeal to Python/Ruby/Perl hackers wanting to learn a different way to think about programming.

I think that was me. FWIW, I find CL's libraries to be adequate in many cases, but certainly not as good as Perl's.

(I have done a few Java projects, and I don't consider their libraries adequate at all. You are either stuck with full-stack frameworks, or a legacy API from 1995. I've also found that most Java programmers that write libraries don't know what OO is, and that makes the libraries painful to use. YMMV.

Slime is also vastly easier to use than Eclipse, even with "emacs emulation" turned on. Again, YMMV. :)

http://blog.reddit.com/2005/12/on-lisp.html

I didn't care too much about the syntax, a good editor fixes this without a problem and it was a good opportunity to look into emacs a bit (usually, I use vim). Surfing through the chapters of practical common lisp when pretty well and understanding was not exactly hard.

However after that, I was faced with confusion. There is a boatload of lisp dialects, each with a boatload of implementations and each implementation as another boatload of libraries that do something looking similar to what other implementations libraries do without being the same or compatible. How am I supposed to select any of these without having a clue? After a few days of back and forth, I decided to close the book lisp for me, because I could not find a way through this wall of selections -- at least not without investing a lot of time. Too much time for too little benefit over python.

HTH, Tetha

(I've been meaning to write about things I've learned from the dozen or so languages I've at least dabbled in, but haven't had the time.)

For example, Nu is one of the coolest languages out there that allows one to do quick and dirty "scripting language" hacks in Objective-C. Due to Lisp's simple structure, Nu was able to directly map Objective-C method call signatures into something that clearly looks like basic Lisp. It allows one to code in 2 languages, but the Objective-C part of the language actually looks very similar to normal ObjC. One of the biggest benefits of Nu is that writing unit tests in ObjC is no longer painful... the whole testing structure is as simple as typical ruby unit test cases.

Clojure is another one of those wonderful libraries that is a must-have for anyone doing normal java. Even basic string manipulation is extremely verbose and annoying in Java, but is probably too heavy to load a JRuby/Jython interpreter... I think that's where clojure helps fill the gap. I recently implemented an "equivalent" of a google-analytics tracker in Clojure and the final result was only around 200 lines of code (with a little bit of java here and there). It's quite nice to use clojure as a glue-language to make all your java libraries work together with little clutter as possible.

I very strongly suspect that the "crazy parentheses" is not actually why most people who hate Lisp hate Lisp. Crazy parentheses are nowhere near the top of my list of reasons, anyway. And, blaming parentheses is the same as complaining about the sigils in Perl or the significant white space in Python; it's just not a very intelligent argument, and can probably safely be dismissed as merely uninformed. Sure, you like what you're accustomed to, but you can become accustomed to different syntax quite easily...one or two weeks is all it took for me to switch from Perl to Python, and then back again a few years later.

A syntactic difference is just a very simple concept to latch on to; both for those who hate Lisp (for whatever reason) and those who want to explain away the people who hate Lisp (without having to address the real, but complicated, problems). There are a lot of very good reasons to hate Lisp, but they take more than one or two sentences to explain, and most folks just aren't going to invest that much effort in talking about something they just don't have that much interest in.

The linked article does mention a few of the very good reasons to hate lisp, and leaves out a couple that I think are possibly even more important:

- Lisp has a community that is generally hostile to newbies and outsiders (mentioning other languages, in particular, seems to be a big source of trouble). Contrast this with just about any other modern dynamic language community. Friendliness is practically religion in the Perl, Python, and Ruby communities (though I think only Perl has a formal religious institution for the purpose at perlmonks.org ).

- A community that has a deeply ingrained culture of NIH. There are dozens of incompatible Lisps, with dozens of incompatible libraries for all sorts of tasks. I've found Lisp to be the most difficult language with which to produce useful software as a beginner of any dynamic language I've tried. Not because Lisp is inferior to Perl, Python, Ruby, etc. but because I found it impossible to find any combination of components that made it possible for me to produce useful software without running into bugs or incompatibilities that my weak knowledge couldn't overcome. Even if Lisp allows for code that's half or a quarter the size of any other dynamic language (which seems an unlikely compression), the sheer volume of excellent libraries in Perl/Python/Ruby means I can write a tenth the code, making those languages a win even if the total line count, including libraries, is higher. I've been told (grouchily, in keeping with the smug Lisp weenie tradition) that tons of great libraries exist for Lisp. Despite this assertion, I've never been able to build even a toy (but useful) project in Lisp.

* The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. You can start coding things like PHP, Perl, Ruby, Python, etc... with a pretty crappy editor and do ok.

* NIH - bingo! Lisp has always struck me as being very insular, with a very strong 'turtles all the way down' mentality. "It would really be best if the OS were written in Lisp too...", whereas the "scripting" languages are very promiscuous in terms of what they will interact with and run on. This has led them to focus on doing what they are good at, and calling out to C or other languages for what they are not so good at, which is ultimately more productive than rewriting existing systems just so that they'll be 100% in your language of choice. (Yes, sure, not everyone in the Lisp world is like that, but I get that general feeling).

I disagree, with a caveat--writing code using a terrible editor requires knowledge of the indentation rules for the language, regardless of whether that language is a lisp, Perl, Ruby, etc.

However (the caveat), although the indentation rules for Perl, C, Python are relatively simple (indent after a '{' or ':', line up arguments), each function/macro in a lisp can have different indenting rules (e.g. in CL compare `let' to `multiple-value-bind' to functions, to lists, to the various `with-*' macros, etc).

Once you know the library for a specific implementation, the indentation rules become more obvious; at this point, using (e.g.) Notepad isn't particularly terrible (until that knowledge is acquired, though, yikes).

Oh, also a weird (maybe crackpot?:-) theory of mine: parenthesis, graphically, don't form a nice, rigid vertical line, but sort of point diagonally, possibly making it just that much harder to see how they line up. In any case, 4 or 8 space indented C/Tcl/Ruby/whatever code is certainly more obvious to the eye.

"A community that has a deeply ingrained culture of NIH."

Lisp is a NIHer's heaven. I know something about it, I've just spent 3 years learning new stuff and reimplementing the universe with it (I'm not done yet. Give it some decades...). Learning Lisp is a friggin' Pandora box. It gives you absolute power (that corrupts you absolutely), it makes you discover crazy powerful and sometimes hard to implement paradigms (ex: Dataflow), and of course you have to try to implement them so you simply never get anything done. Sure, you do things The Right Way, but the investment in implementation and learning time is absolutely prohibitive. Gotta admit I'm not sure if Lisp made me a NIHer or I was just drawn to Lisp because I'm one but Lisp sure is an aggravating factor for that.

A few days ago I finally decided to STOP LEARNING and STOP REIMPLEMENTING THE UNIVERSE for a few months so I can finally launch my startup (some utility site for a niche MMORPG).

Lua, while even more Scheme-like than Python, was designed primarily for use as an embedded scripting engine in another languages (typically C or C++). Instead of putting effort into making Lua clones of typical libraries, they worked on making re-using other languages' existing libraries quite easy. It seems to stand the whole NIH thing on its head, too. (Though, languages such as Chicken Scheme that compile to C can inter-operate better than most.)

Do you mean that people who hate lisp because of its parentheses are uninformed; or do you mean that thinking that this is the reason people hate lisp is uninformed? The first is about languages; the second is about people.

Assuming the latter, what's the evidence? Many people complain about parentheses, so it seems that it is an active reason, but without a rigorous survey ("Why do you hate lisp?"), it's hard to know.

The issue with parentheses is not about "hate" at all, but confusion. If you are 100% determined to learn something no matter what, you can probably learn it. But in reality, when you start to learn something, you are also assessing if it is worth the effort of learning.

The context of my first experience with lisp was that it was supposed to be more "mathematical" than other languages - and so I assumed the parentheses were used as they are in expressions, that is, for grouping. But they aren't used in that way in Lisp - they mean function call, like f(x), but with yet another syntax. So, my 5 minute cursory foray into Lisp ended with me concluding that Lisp was unexpectedly inconsistent. Since that's against my usability values, I didn't spend further time on it (since then, I have spent further time).

I didn't hate the parentheses; I just found their meaning elusive.

Both, actually. But moreso the folks who complain about parentheses. I suspect that anyone who uses that as their reason for not learning or liking Lisp simply would never consider Lisp long enough to know anything more about the language. I just think it's more likely because they like "industry standard" languages, and have no obvious on-the-job use for Lisp, but they don't want to say "I am intellectually incurious about languages and different programming paradigms". I think those same people would never learn Lua or Haskell, despite a distinct lack of crazy parentheses.

Many people complain about parentheses

Many people complain about significant whitespace in Python and sigils in Perl. Either one has orders of magnitude more developers and more code being written in it on a daily basis. It is a triviality, and the kind of folks who pick out trivialities to complain about are not the kind of folks you can convert. They're not going to learn your favorite language, unless you make it look exactly like their favorite language. Since Lisp can't look like Java or C# or C or Visual Basic or PHP, without losing a lot of what makes Lisp Lisp, that's not a useful pursuit.

So, I'm simply saying that talking over parentheses over and over again is ignoring the real problems and focusing on the one that everyone knows won't change. It's a perfect flame war talking point, but it's not what's keeping people away from Lisp.

Unfortunately, I think the community is about as likely to change.

I agree. They've had longer than anyone to figure out the "community" thing, and they've self-selected into near obscurity.

A good manager will either 1) research more thoroughly and come up with a more sensible reason to not use Lisp (there are many reasons not to use Lisp for many kinds of projects) or 2) delegate technical decisions to the technical people he hired and trusts to make those decisions (with some way to hold them accountable for meeting objectives).

IMHO, there is quite a lot of support for the argument that modern day scripting languages are getting closer and closer to becoming lisps, except for syntax and the macro system. (Maybe Perl 6 will have meta-language power enough to equal the macro system? I should start learning it.)

I've never really understood why there are no successful projects to transfer code between the S-EXPR parenthesis-based syntax and some Algol-like notation; if that managed to also copy comments between the formats and auto formatted well, it would be an easy introduction for new lispers.

Not only does it have full-on raging macros, you can redefine the languages own syntax inline. Check out one of Larry's recent talks about STD.pm (here's a Google Tech Talk from last year, which is nowhere near as funny as Larry usually is, but is still quite informative: http://www.youtube.com/watch?v=JzIWdJVP-wo )for a real "when you see it, you'll shit bricks" moment. Perl 6 is far more intimidating than I ever realized. They seem to have looked at everything good about Perl (and a handful of other languages) and said, "Let's do a lot more of that." It's somewhat scary how much more of "that" they've done. So, there's macros from Lisp, lazy evaluation from Haskell, redefine-able grammar and syntax from I dunno where, a new regex language, etc. It takes TMTOWTDI to obscene new heights (kinda like Lisp). If power is the sole determining factor in what language you choose, there's a strong case to be made that Perl 6 is the one you want. I don't know that I entirely buy that (if I did, I guess I'd be using Lisp), but I'm hopeful that the real result of Perl 6 will be a language as capable as Lisp with a community and library culture as strong as Perl 5.

To take most everything good existing and sum it, is how you make Perls. :-) I'm not arguing here, I do Perl today.

You should have put the content of the last sentence first; too few will read it.

For example, if you're typically a lisp guy, you would probably write code like this: (init (alloc ApplicationDelegate))

But if you're an ObjC person, you'd do this: ((ApplicationDelegate alloc) init))

And strangely, if you replaced the parentheses with normal square brackets, you'd be looking at syntactically correct ObjC code! In Nu you can mix and match your sexprs and algol-like notations as long as you know what you're doing. The finished code would be something a lisp developer and ObjC developer could both understand without knowing too much of the underlying details.

Interesting idea to level a scripting language on using the message passing mechanism of Obj-C -- and so integrate the resulting code with the compiled Obj-C!

Thanks for making me look!

Yes, but, I'm sorry, not every computer science advance came from Lisp. (Not singling you out in particular, berntb.) Insisting otherwise makes one sound condescending, fanatic, and/or naive. There are good ideas in Lisp, yes, but there are also good ideas in ML, Lua, Awk, SQL, Smalltalk, Prolog, Haskell, SNOBOL, etc.

Lisp is cool as a clean embodiment of the Lambda calculus and all, but if people stopped treating it like it were a divine revelation, other people would perhaps stop getting the impression that Lisp users are [insert torrent of unflattering adjectives].

(The Scheme community is generally much better about this than the Common Lisp community, but the Scheme community at large also seems to spend more time trying to actually move the language forward rather than insisting that some old standard has everything people will ever need.)

AFAIK, not even the lisp snobs would argue that everything worthwhile happened in lisp; they argue that most of the lisp characteristics was copied by everyone. For some values of "most", it seems like a very good argument.

Just, it boggles my mind how many ideas from barely ten years ago seem completely unfamiliar to most programmers. As Steve Yegge put it, "Oh, right, I keep forgetting: you were born in nineteen-ninety something, and you're nineteen, and I'm ninety-something."

I'm only 27, but I'm starting to feel like I'm at least one programmer-generation back (and, occasionally, the cranky old man yelling, "get off my lawn!"). I find a lot of inspiration in the 70s-80s Unix-era books, for example. While some of the surface details have changed, those guys wrote lucidly about ways to design useful systems without them growing into impossibly tangled monstrosities (even before C++...). A lot of issues programmers struggle with today have been mulled over for decades, and there's a lot of good advice if you look. The field hasn't changed that much.

I see ideas that keep getting rediscovered, and sometimes it's really sad how few stick. Lisp had a lot of great ideas in it, yes, but it's not the only old language that did, and the way it gets exalted that way touches a nerve of mine sometimes. (FWIW, the second paragraph in my response above was saved right as the edit window closed. I was still rewriting it, and it sounds harsher than I would have kept.)

And then...

Be happy kid, it gets worse. :-)

Exercise, take vacations and make certain you relax enough (a meditation-course is good; there are non-religious ones). Also, be careful with your teeth; an infection I had no other effects of, made me chronically tired for a long time and really destroyed my life (I thought I had burned out).

And work with stuff you care about, otherwise you'll probably hate yourself and everyone else.

Most other stuff you seem to know.

Sorry for that, but a 20-something trying to sound world weary needs a pat on the head. :-)

How's about conceptualizing the problem less as "People don't come to the light about how Lisp is not as problematic as they think it is" and more as "We need to explain better how people's lives are going to improve if they learn and use Lisp". (I know, I know, I may have just committed the sin of marketing. Please forgive me.)

I do not have a Lisp-sized hole in my life right now.

I know (and really like) Scheme, but the balkanized Scheme ecosystem can be very confusing to curious onlookers, and can make finding one implementation with all the libraries relevant to a project difficult. There's the tiny core language, then there's a bunch of SRFIs that implementations choose whether to support, and implementations are all over the place as far as quality, libraries, and portability. (I eventually settled on Chicken.)

I learned some Common Lisp, but ran into so many portability and library problems, for stuff that would be trivial in Python, that I ultimately gave up on it. In retrospect, Scheme is a much better fit for my taste, anyway.

For a while, Python was my default language for real work. (Lately, I've switched to Lua. They're quite similar, though Lua has incorporated more of Scheme's good ideas, has more of its own, and has a much cleaner design, IMHO.) While neither has macros, they have a collection of libraries, an active community, an obvious standard implementation, great support for interactive development, a decent syntax, etc. Macros aren't everything, and SwellJoe's comment about NIH (http://news.ycombinator.com/item?id=550634) is absolutely correct. (Lua's design, in particular, assumes from the start that it will be embedded in something else. It's very simple to use it with other languages and their libraries.)

While I don't know Ruby (Python & Lua already fill that niche for me), I'd expect Ruby programmers find similar productivity there.

Also, I think people overuse macros. Certain people have put a lot of time into promoting them as the biggest asset of the language, which tends to encourage people to use them where they're not only unnecessary, but likely to make code harder to understand / maintain. (See, for instance, http://news.ycombinator.com/item?id=542746. Especially: "Q: What do you get when programmers design a language while trying to get something else done? A: PHP")

While I'm not knowledgeable enough about Ruby to say for certain, I could see making a big deal about "monkeypatching" causing similar problems there. Maybe the Ruby community encourages more restraint, though. Anybody?

I won't even say that libraries are a real problem. Sure there is no CPAN, but still there are a lot of very good CL libraries around, and they are not really hard to install.

But:

1. The language is sophisticated. This is a "problem", in the sense that such a language takes time to study. It will never be popular. The Condition system and CLOS, for example, are way more complex and versatile than, say, the equivalent areas of Java. And then there are macros. Common Lisp has not been designed as a mainstream language for mainstream programmers. It is, I fear, an elite tool.

2. Certain kind of operations are inconvenient. Maybe when CL was designed, sockets, multithreading, text processing etc were not so popular. But now, it feels like CL has not really adapted well to the modern world. Having to install a compatibility library for using sockets is reminiscent of things like "trumpet winsock". Does not feel very cutting edge.

3. The literature is lacking. "Practical Common Lisp" is very good, but one book is not enough. For example, what are the best practices to organize large CL programs? No book tells it (maybe some obscure out-of-print text that I have not yet tracked?). What about programming idioms, or patterns as you prefer? Apart from an ancient presentation by peter norvig, nothing exist. And so on.

4. The ANSI standard is a big blessing and a big curse. It is a well-written and smart opus. But nowadays no one has the resources for a new standard; both in terms of money and focus. This means that ANSI CL seems an ancient pinnacle of beauty which will never be equalled and certainly can not be improved. (the perfection of ancient architecture, as seen by renaissance architects, comes to mind). This makes CL a splendid but dying civilization.

5. I have a feeling that the community is slowly dying as well. While in recent years many CL sites and blogs have appeared, comp.lang.lisp has lost many important contributors. Nor I can really blame them: while still a wonderful language, CL is nonetheless petrified, and I suppose one may became slightly bored after a decade or two of discussing the finer points of the Standard.

Christian Queinnec's _Lisp in Small Pieces_ is another absolutely brilliant book on Lisp, btw. It and PAIP are both about equally expensive, but both are well worth it IMHO. (FWIW, PAIP is probably of more interest to people with no intention of using Lisp.)

(Also: Remapping your keyboard helps, whether you do it in your editor or overall. And, I did not write the above just to say "IMHO FWIW PAIP". Honest. :) )

p.s. I've never written anything longer than a textbook exercise in scheme, so i don't know if you can actually write real stuff in this(or how hard it is) but playing with it is really fun, you should to it just for that.

Sadly, this doesn't seem to have struck the heart of the problem (although Lisp-in-a-box that came with PCL seems to have done it for some people).

Think about why Java is so widely used. I would argue that it's because of one thing: portable packages.

Lisp was closely associated with AI a few decades ago.