Common Lisp Implementations in 2023

I always like seeing Common Lisp links, but personally I was a bit put off by the very strong anti-commercial comments about LispWorks and Franz.

I had a business idea requiring Common Lisp a few years ago and I purchased a LispWorks Professional license. Small standalone executables with a tree shaker [1] and I has received very good support without paying for the high priority support service. I also paid the maintenance fee last year for continued updates. Coincidentally, I am an advisor and chief architect for a small AI company and they use LispWorks also.

Many years ago, I worked as a consultant on a medical AI project and my customer paid a fair amount of money to Franz for software licensing and tech support that included helping with development. Incredibly useful!

I also love open source Common Lisp and Scheme implementations.

Anyway, I would respectfully suggest to the author to maybe tone down the rhetoric a bit since different individual developers and companies have different requirements.

[1] you can also make small standalone apps with SBCL by building from source and setting a flag to allow compressed heap files.

There's a weird spike in new accounts with what appear to be AI generated comments in this thread.

One problem I run into when learning Common Lisp is ASDF. For some reason I can't figure out how to use it properly. For example, when I open a system definition in a new REPL, what's the expected workflow? I'm using emacs and slime by the way. Maybe my environment is set up wrong. I also have to prefix the `defsystem`s with `asdf:`. When I look at examples in open source projects they just straight up use `uiop` functions and `defsystem` in their `.asd` files without the package.

For a period much earlier in my career (think early 00's) I seriously desired to work in Common Lisp professionally. Through a series of life decisions and other opportunities, that never really happened. But I continued to work on Lisp projects on my own and use it for various things. I don't consider it a "superpower," and I don't think it makes me 10x more productive or anything like that. Most modern languages have stolen most of the thunder from Lisp (other than macros) so I would be hard-pressed to recommend it for greenfield development.

That said, I love working in it. I don't have any illusions that it will make a "comeback" or that I will ever make money writing it (I long ago switched to looking for job opportunities based on the problem domain rather than the toolset), but I continue to use it personally because it makes me happier than any other language.

There was a great comment about LispWorks over on the reddit discussion, linked here[0]. I really need to give it a shot at some point, especially as someone doing CL professionally.

I know that Lisp is popular on HN but that it's mostly a kind of zoo like experience where the proper devs come here to gawk at us but I really cannot recommend it enough for any kind of work. We use it for stock market analysis but almost every piece of code we write is CL. I'm currently trying to convince people to switch over our CSS over to LASS[1].

0: https://www.reddit.com/r/Common_Lisp/comments/11979q4/commen...

1: https://github.com/Shinmera/LASS

I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are hashing out a spec written decades ago and not trying to improve what's obviously lacking -- a full modern standard library! Trying to piece together functionality from here and there (and Quicklisp which is an unversioned mess) will only take you so far and in the end you will realize the amount of time wasted chasing this great language! AFAIK Lisp needs more backing from the heavyweights to make any reasonable progress which I'm sure won't happen.

It may be worth mentioning that CLASP is one of the only languages/runtime systems that can interoperate with C++ code directly - say, to catch C++ exceptions, or pass around std::vector<T> and so on.

It's also quite remarkable that the project was started by a chemistry researcher.

Are there any serious attempts at reworking the Common Lisp standard for more modern problems?

I know the space is active, but when I see the old bright yellow CLHS linked to from documentation sites, I just frown a bit. The Lisp community very nearly goes out of its way to be unhospitable to the younger generation of coders, and downright dismissive of modern techniques like containers and DevOps practices.

Not that the Scheme community is doing a radically better job, but at least the RnRS standard is marching forward at an acceptable pace.

A few years ago there was CL21, but it didn't really garner enough support from the community to really take form into anything worthwhile. I think we need a "Lisp for 20XX" council or something to gather up ideas and begin a reconstruction era for Lisp in this century.

I had a great time writing common lisp for the better part of 2022, including doing about half of Advent of Code in it. It's such an awesome language and once you get an understanding of macros, it really does feel powerful.

Unfortunately, I hit a bit of a wall. I don't really have any personal projects to work with CL, and if I used CL (or any lisp/scheme dialect for that matter) at work I'd be in trouble.

Nice to have in the back pocket though, and I'm excited to reach for it in the future.

One should note that while it is true that the last CLISP release was a long time ago and there is not a lot of development going on right now, it's not dead. Bruno Haible just commited last week.

The repository is now at https://gitlab.com/gnu-clisp/clisp

First time one of my articles lands on HN! Feel free to ask any follow up question.

I would like to learn Lisp but am easily confused with where to start. What implementation do I use? On a general level do I start with CL, schema, racket, etc (apologies I know this thread is about common lisp). It's all very confusing.

I'm like this with most things, like I want to learn Forth too but have that same problem. I learned vanilla JavaScript because I didn't know where to start with the 1000+ frameworks; and as a result am learning flutter/dart for cross platform apps.

Any advice would be much appreciated!

CLISP is excellent for learning Common Lisp; it has a readline-based REPL with editing and tab completion, so you don't need anything other than the CLISP installation.

The licensing server back end for the Tankan kanji learning application runs on CLISP.

No love for NPT (<https://github.com/nptcl/npt>)? Well, I get it, it is very, very new.

One note about ABCL is that it doesn't support TCO, which the Common Lisp spec doesn't mandate. For people who want a Lisp on the JVM and really want tail calls, I would recommend checking out Kawa (<https://www.gnu.org/software/kawa/index.html>).

Compared to languages that have a single implementation, have multiple commercial and open source implementations in reasonable states of continuous development seems like a good place to be.

ECL license is LGPL-2.1-or-later (not LGPL2), the same applies to Clasp (which was forked from ECL).

n.b isn't this thread infested with bots? 4 or 5 nicks created 4 days ago with incomplete messages..

> The free “Personal Edition” limits the program size and the amount of time it can run, making it pretty much useless for anything but evaluation.

Also very good for education purposes.

This LispWorks comment on reddit is very interesting:

---

[cite]

As a Lispworks user, yes it is super pricey, but it does make sense for certain people. Arguably, Lispworks provides features that aren't available in any other programming language, Lisp or not.

* Support for just about every platform I can imagine. Yes it's expensive, but if I want to port to a new platform I can pay Lispworks, and get it over with. It'll mostly work without too much changes. It works on Android, iOS, Windows, Linux, Mac, and some really obscure systems.

* Application delivery with tree shaking. May be there are other languages that do this, but I haven't worked with something like this before in my career. (Maybe proguard for Java, but that's very rudimentary compared to LW's delivery). The tool I work on delivers a binary that people need to download during the CI jobs for every run, so having it be 100MB is way too big. After compression, my LW delivered binaries come to around 9MB.

* You mention support being expensive. Actually, for simple support questions LW does a pretty good job of responding back to you. I've asked tonnes of questions over the years, and have not paid for a separate support contract apart from the yearly maintenance contract. I suspect they like people asking questions, because then they fix those bugs and it becomes even more rock solid.

* The documentation is glorious. And in the off-chance that I need to know something that's not documented, I just mail them and they'll respond usually by the next working day.

* Very stable Java support (although the API could be better), let's me use the entire Java ecosystem of libraries when I need it.

* The platform itself is rock-solid. Now SBCL is fantastic, but when I ran my servers on SBCL, I would have a crash every now and then. With LW, I can have my server running weeks (current uptime is a month) with reloading code multiple times a day, and everything is still super stable.

There's more, but I think the rest is more negotiable. For instance, the FLI is a lot more polished than using CFFI, which makes a huge difference in productivity when writing native code. Or the fact that its remote-debugger facility can be used as a very stable protocol to programmatically control a remote LW process. I don't use the IDE btw, so I'm not even considering that. I don't use CAPI either, but I mean to someday.

2023, Arnold @tdrhq of Screenshotbot (https://github.com/screenshotbot/screenshotbot-oss) on reddit: https://www.reddit.com/r/Common_Lisp/comments/11979q4/common...

[/cite]

Franz releases updates continuously bringing in new features. The update.sh handles these patches, and new items.

Sad to see Clozure CL abandoned, that was my main squeeze back in my lisp days (I was on Windows and SBCL wasn't cut out for it at the time). How's SBCL on Windows these days?

Common Lisp implementations in 2023:

- SBCL

Everything else is de-facto dead or in a proprietary silo.

Lispworks starts with an affordable hobbyist edition. There is also a hobbyist development edition.

if sbcl significantly faster than racket why and when do practitioners use racket?