Right, I should’ve looked it up on CLiki 😅Thanks for these references, you’ve helped a lot 🖤

Right, thanks for the gist!

I’m not yet using cl-repl because I want to have distinct tools composed to a usable whole or at least try to do that before surrendering to complete setups like cl-repl. But thanks for the recommendation anyway!

Oh wait, it really ships with a GUI-based IDE… I’m convinced—Allegro is good, especially when paid. When talking about free version, my non-introspection comments still apply, but they are kind of implied for a free version of proprietary product.

Yeah, that sums it well enough. I pin my hopes on ECL and Clasp because of portability and active development.

CCL is mostly only on life support. The native port to the Apple Silicon Macs isn’t under way. CCL isn’t making any progress.

Didn’t know it’s that bad 😢 A shame—CCL is a nice piece of work.

This is the index of the Allegro CL documentation: https://franz.com/support/documentation/10.1/doc/contents.htm

I’ve been overly generic, I guess. What I meant was answering a (supposed) OP’s request for raw implementation usability. Which is REPL, introspection facilities, SLIME/SLY integration. Allegro is not perfect when viewed from this perspective. Proprietary implementation makes it hard to inspect what’s going on in the image and optimize the code comprehensively:

• disassemble is useless.

• Inspection is locked to what they provide—even SLIME/SLY merely uses the implementation-provided function for inspected parts. On other implementations, SLIME/SLY provides a lot of auxiliary info that implementation doesn’t explicitly provides.

• In general, you can’t override the useful parts of the REPL easily: defining new REPL commands is a pain, building GUI tools inspecting the image is either parsing the unreliable raw output of Allegro-provided functions or giving up and using what they provide.

Given that OP likely asked about the general development experience, and that I’ve done a lot of work with basic text REPL interaction on all the implementations I listed above—Allegro is not the ideal basis, especially for learning.

The documentation and the additional products they provide is good, but that’s beyond the basics that OP is probably interested in.

I don’t know many open source Common Lisp implementations on this level.

Fair, I’ve been overly generic too. To me, the basic inspection and interaction is smoother at least on SBCL and CCL, which is, like, two out of five? somewhat maintained implementations.

TL;DR: Use SBCL or CCL. Others—maybe, but likely in their own specific niches.

I want to give more chances to implementations there are, so here’s my experience, in the order of preference:

• SBCL is good. De-facto standard. The REPL experience is… not the best, but practical. Debugger loop is snappy, though.
• CCL (Clozure Common Lisp) is extremely good for development: it is attentive to style, it has exhaustive type checks, it has a nice REPL (probably the best of open-source implementations, on par with Allegro) and a debugger with actually useful stack traces.
• ECL is embeddable, and that’s its biggest value proposition: you can run it anywhere C runs and you can interact with C-based software easily. Beyond this platform-friendliness, ECL has reasonable code optimization abilities and a practical REPL.
• ABCL is useful if you interface with JVM. So if you need to work with Java in Lisp, it’s either Clojure or ABCL. Implementation and REPL experience is somewhat simplistic, but let’s give it a chance.
• CLISP is abandonware, even though the riches of the golden age when it was researched and worked on are still there.
• Allegro is proprietary, which sucks. Given that it’s proprietary, it doesn’t have as much contributors as, for instance, SBCL. So it actually is worse than open-source impls. But it has a nice inspirational REPL. If you don’t need a commercial support license for a huge company, then you likely don’t need Allegro.

I haven’t tried Clasp, Corman, CMUCL, and LispWorks. So no review for them. I tried GCL, but let’s not talk about that.

CL is, like, fourty? years old now. These books describe the standardized language, so most of their gotchas apply to any conforming implementation. So yes, the books are “OLD”, and yes, they are “GOOD”.

To add more context to this response: Java has this notion of static methods that belong to classes, compared to the regular methods that belong/act on instances. So ABCL’s jmethod is to call a method using an instance, while jstatic is to call a static method using a class. Math.sqrt happens to be a static method of Math class, so use jstatic. Once this static/regular distinction is cleared up, ABCL interface becomes quite usable.