> 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.

I'm pretty sure SBCL compiles everything too. From "Compiler-only Implementation," section 2.3.3 (page 14) of the user manual (http://sbcl.org/manual/sbcl.pdf):

SBCL is essentially a compiler-only implementation of Common Lisp. That is, for all but a few special cases, eval creates a lambda expression, calls compile on the lambda expression to create a compiled function, and then calls funcall on the resulting function object. A more traditional interpreter is also available on default builds; it is usually only called internally. This is explicitly allowed by the ANSI standard, but leads to some oddities; e.g. at default settings, functionp and compiled-function-p are equivalent, and they collapse into the same function when SBCL is built without the interpreter.

It does by default, though technically, it has an interpreter available if you need it - see http://www.sbcl.org/manual/#Interpreter.

Actually Franz Lisp is a pre-common lisp used primarily with BSD on vaxen.

http://www.softwarepreservation.org/projects/LISP/maclisp_fa...

... and M68k Sun workstations, and the CCI Tahoe, which was a late-80s Vax clone with about 6x the speed. (I did the port to the Tahoe as an undergraduate.)

>I use CCL because 1) I like the IDE and 2) its compiler is fast so you can always compile everything essentially for free.

Just to add to the above, I like CCL because it gives nice compiler messages --sometimes it warns me about things SBCL won't notice.

What resources would you recommend one read to understand more about debugging facilities in Common Lisp?

Debugging facilities are not standardized so you'd need to consult the documentation for whatever implementation you are using. e.g.:

https://franz.com/support/documentation/10.1/doc/debugging.h...

http://www.sbcl.org/manual/#Debugger

In [Successful Lisp, how to understand and use CL](http://www.communitypicks.com/r/lisp/s/17592186045679-succes...) there is a chapter on debugging. Book's site, free dl: https://successful-lisp.blogspot.com

Also, it may not be necessary to master the most complicated machinery: compiling function by function gives lots of hints, and the very nice [log4cl](https://github.com/sharplispers/log4cl/) is handy.

I have found this series of articles to be very helpful:

http://malisper.me/debugging-lisp-part-1-recompilation/

See the LispWorks IDE user guide: http://www.lispworks.com/documentation/index.html

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

>>I don’t know if you remember this but we sparred a couple of times on HN few years ago.

Hey, I apologize if that was something that hurt you in anyway.

I discovered Lisp a few months back, I had of course heard of it long back, but kind of discovered using it only months back. I don't code in Lisp at day job or full time. But many of my problems related to understand data structures and algorithms have vanished since I started thinking of them in Lisp.

Mostly because I started to think in terms of recursion well, and other list manipulation stuff feels like it just comes to naturally. Not sure why this, or its unique to me. But for some reason I find it very easy to think and work with trees and graphs when I think of them as lists.

Always looking forward to learn and do more.

No it was cool :)

Yeah, most of incidental complexity vanished away once I start using clojure. Lisp is pretty cool in that there is very little to learn in way of syntax and ceremony.

If you are new to functional programming, I suggest understanding reduce well. Understanding it forms the basis of higher order functions. Also half of clojure core is implemented with reduce.

Also, I highly suggest watching the talk “simple made easy”. One hour of time spent there pays off in many many months/years

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).

For some reason ITA (now at Google) had people who advocated moving from SBCL to CCL for their application(s).

I recall reading that the speed of compilation was a big issue for them with the size of their application.

Yes, I recall that they were using Clozure for dev and SBCL for production because of that at some point.

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.

>>For example on the Deep Space One spaceship the application was deployed with LispWorks

>>Imagine your application is a CAD system written in Common Lisp with CLOS (there are and were a bunch of those).

For some one considering seriously writing Lisp as a full time job, are these kind of opportunities still there?

I mean how big is Common Lisp usage these days?

Depends on where one is living.

Syscog is a Portuguese company focused on Lisp based solutions.

http://www.siscog.eu/index.asp

https://franz.com/success/customer_apps/scheduling/siscog.lh...

I have no idea, but it's 'small' - though there are still two commercial vendors. I'd guess that Franz still sells into some corporate environments and into government/military/security/... Domains people usually don't hear about and end users might not even know that they are using Lisp. If a Lisp-based graph database powers some customer-relationship application at a telco, then nobody will know that it is Lisp. There is also the myth that some military commander won't let their Lisp Machine application go, because it's the only one that never crashed in their data center. Former Swissair had an expert system to improve seat allocation (IIRC), which they maintained for more than a decade - it's might even still be running in Lisp - nobody would know that it exists and how it works... There are also Lisp applications which monitor and control processes in chemical plants - for the end user it's not visible what this is written in.

A bit out of topic but I remember you mentioned you were working on a lisp book and asked what we would wanna see on it. Well for me, I'm super curious about compiler development, and I think, in the topic of this thread, maybe a chapter on writing a recursive descent parser for JS? building a transpiler? or using lisp as a intermediary with LLVM IR? somewhere where either DSL || "Code is data" and the true advantages of lisp shine through, and I would love that from an experienced lisper. Also if you could go into some use cases for tunable compilers that are seldom elaborated when that is mentioned as a huge lisp advantage! Thanks for giving the community your time in advance!

That must have been someone else.

>For some one considering seriously writing Lisp as a full time job, are these kind of opportunities still there?

Seconded.