> Allegro CL or Franz Lisp.

Same thing. Franz is the company. Allegro Lisp is the product. Like "Apple Macintosh computer."

> But why is it 'high performant' compared to other implementations? Like say CMU CL(now SBCL).

Somewhat better compiler, but mainly lots of extra features (better debugging, graphics, better libraries).

> why would one use Clozure CL instead of SBCL?

I use CCL because 1) I like the IDE and 2) its compiler is fast so you can always compile everything essentially for free. In other CLs you have to choose between running in compiled or interpreted mode, and that can sometimes cause problems. CCL doesn't have an interpreter at all. It always compiles everything and that makes it easier to use.

SBCL [0] is a fork of CMU CL [1], and both are actively maintained projects.

[0] https://gitlab.common-lisp.net/cmucl/cmucl

[1] https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/

Hi kamaal, it’s nice to see you interested in cl. I don’t know if you remember this but we sparred a couple of times on HN few years ago. I have been on this path before and happily settled on clojure for a few years now. I don’t know if it applies to all cls, but what nobody told me was how little I have to worry about when writing code in clojure. I stopped paying attention most of the Language and instead spend time on solving the actual problem. It is very liberating. See the talk “simple made easy” by rich hickey if you haven’t already. Also most psychological and process incl. debugging barriers come down when using clojure

If by 'older posts' you mean early 2000's and prior, the open source Lisps weren't as many or as good as they are today. CCL is open source (back then it was closed source under the MCL banner), SBCL didn't exist in it's current form (that was announced in 1999) etc. In general, each decade back you go, think of whatever open source software that even existed as being significantly less powerful, performant and buggier. Many open source projects (esp. the GUI applications) started life as bad imitations of not much better commercial software vs. what you're used to seeing today. And to top it off, you were running it on radically less powerful hardware (in the early 90's you could still watch windows on the screen being redrawn on 'high end' hardware) so any software performance issues you had were magnified by the systems you were running on.

Not just Allegro, from what I read, Lispworks is also noticeably faster then SBCL (you might be able to find some comparisons for a practical system by googling for elPrep, which is now written in Go but used to be Common Lisp and ran on both Lispworks and SBCL). Concerning the appeal of Clozure CL, I think people have traditionally used it for faster dev turnaround due to better compilation speed than SBCL (which in turn typically generated faster code).

Franz Lisp does not exist anymore. It was a dialect like Maclisp at that time. It has been replaced three decades ago with Allegro CL - by Franz, Inc..

The 'fast' Lisps are often the native Lisps (SBCL, Clozure CL, Allegro CL, LispWorks, Lucid CL, ...). For selected applications some implementations were more specialized (for example GCL with fast numerics for Maxima)...

SBCL has the advantage of some more advanced type handling.

But fast isn't just low-level benchmarks. It might mean fast for a certain application. For example on the Deep Space One spaceship the application was deployed with LispWorks (and not OpenMCL/Clozure CL) because LispWorks had the best GC (soft realtime) and could be running on a hardened PowerPC processor on a real-time OS.

And 'fast' in Lisp is also important for mostly unoptimized, but compiled, code with full runtime checks and lots of flexibility. Stuff which would be 'full debug' mode in C++. For example the typical Lisp Machine OS could run in a full development mode without much runtime speed penalty - just lots of space penalty. It still had to deal with the window system (written in Lisp), disk access (written in Lisp), interrupt handler and scheduler (written in Lisp) ... Is that 'fast' enough for the interactive user? Benchmark-wise the system might be slow, but it might perform well for applications running multiple threads and lots of interrupts.

Imagine your application is a CAD system written in Common Lisp with CLOS (there are and were a bunch of those). It might need a large address space and zillions of CLOS objects. Will it run fast enough for interactive 3d workloads? How fast is the GC? How fast is the CLOS implementation? How does it deal with FFI operations into OpenGL... Stuff like that had been developed with Lucid CL and Allegro CL. At a time when CMUCL still was printing GC messages to the terminal...

Nowadays a lot of machines are "fast enough" and have lots of memory. But when one needed a 64bit SGI for a demanding application, Allegro CL was the thing to use. I think the IDE for Crash Bandicoot was Allegro CL on an SGI. Later similar graphics applications in Lisp ould also run on large Windows NT machines with faster graphics cards. Today Allegro CL is also the only CL one I know, which has a partly parallel GC - a demanding application like their database and knowledge-bases drives the need for faster runtimes. Lucid CL no longer exists (though LispWorks provided support for it), but it had a compilation mode for full-program compilation, which enabled good runtime performance. Many commercial applications had been deployed with it - until the company went away - after investing lots of money into an advanced C++ IDE which did not fly on the market. With something like LispWorks and Allegro CL one can develop normal-looking and fast applications for the desktop - stuff which feels much less sluggish than your typical Java desktop application and has useful interactive performance.