I consider Allegro and Lisp Works more useful, as they are closer to the original Lisp Machine/Interlisp-D development experience.

Load McCLIM into SBCL. See https://github.com/McCLIM/McCLIM or https://mcclim.common-lisp.dev

It's available also via Quicklisp.

Screenshots of interesting apps are here: https://mcclim.common-lisp.dev/excite.html

They should really appear in README.md!

Too bad this GUI framework doesn’t work on the most widespread end user OS.

Please provide a proposal on which UI API a Windows build of McCLIM should target.

This is a serious question. What is the best way of putting lines and text on the screen on a modern version of Windows?

Win32 should suffice.

You put lines with Direct2D and text with DirectWrite.

Why not? Isn't there X11?

Yeah, I guess it has hardly changed, right?

McCLIM has been changing a real lot, actually, as of late, with many useful changes and bugfixes and applications that use it, such as Clouseau the inspector.

Thanks, I guess it is worth a revisit.

Is Lisp Works compliant CL, such that any CL written in their IDE will work with SBCL too?

Any ANSI Compliant CL will work on all implementations that are ANSI compliant

So in short, yes, except for any third party libraries

Okay cool, I guess my question is how heavily do third party libraries feature in Lisp Works such that you’re then tied to their ecosystem?

For a lot of things there are portability libraries that bridge vendor extensions between implementations. So, in practice, you can use features that aren't part of the ANSI standard (threads, sockets, ffi) without tying yourself to a single implementation. Also, FFI is pretty trivial in most implementations.

Cool! Thanks for your response. So would you suggest Lispworks as a good development environment for new Lisp hobbyists who aren't keen on Emacs?

Lisp Works is way better than SBCL ;)

Its just that open source communities have the most vocal proponents, but the closed source users tend to keep quiet and just get to work. Generalizing to some degree of course

And SBCL comes from CMUCL, most of the best parts of it are from that stellar implementation

I've been a professional user of SBCL and LW. They both have merits.

LW has better package delivery and a stellar GUI tool. LW is otherwise slow and requires non-portable APIs to get reasonable performance for some kinds of low level code.

SBCL is cheaper, way way faster (in almost every dimension), more portable, better integrated with most OS environments, and provides better static diagnostics. It suffers from having a meh garbage collector and meh delivery mechanisms.

There are quite a bit improvements in SBCL over CMUCL. I like it.

Anything in particular? Its something I have searched the web before, but not much information on the topic

well, SBCL is 64bit, has native threads, can be built from another Lisp, the type inferencing is improved, the whole build process is totally painless. I can build a new SBCL in under a minute from scratch using the installed older SBCL. I can install it from Homebrew on my current Mac. It runs natively in 64bit on my M1 Pro Mac. I also like the Unicode support better in SBCL.

CMUCL is still 32bit, AFAIK.