SBCL: New in Version 2.1.0
sbcl.org
sbcl.org
https://github.com/melisgl/mgl
He's won several ML competitions and works at Deep Mind now, so as far as Common Lisp fans with strong street cred in up-to-date machine learning go, he's probably a good starting point.
[1] https://github.com/gwkkwg/cl-containers [2] https://github.com/gwkkwg/cl-graph [3] https://lparallel.org/ [4] https://github.com/cbaggers/rtg-math/
[1] https://www.reddit.com/r/lisp/comments/kburda/is_there_a_goo... [2] https://github.com/40ants/teddy [3] https://github.com/numcl/numcl
Kudos to all SBCL contributors!
Also, do you have any tips on landing a Common Lisp job for someone who's already in the middle of their career (30s, senior dev)?
As for landing a job outside of academia - my advice would be to attend some of the regular Lisp meetings (See http://planet.lisp.org/, or https://european-lisp-symposium.org/). There is usually some recruiting going on at these meetings. And even if not, you might meet fellow hackers that know about job opportunities.
https://franz.com/success/customer_apps/scheduling/siscog.lh...
* Recommendations on learning Common Lisp: https://news.ycombinator.com/item?id=25442155
* On Lisp communities on Reddit r/lisp and Freenode #lisp: https://news.ycombinator.com/item?id=25543565
* Observations on State of Common Lisp Survey 2020: https://news.ycombinator.com/item?id=25291780
* Lisp in Vim with Slimv/Vlime: https://news.ycombinator.com/item?id=21735148
* Emacs4CL (a tiny quick starter ~/.emacs): https://news.ycombinator.com/item?id=25440690
Like many others commenting here, I too use SBCL because of its good performance. I keep CLISP around mainly for nostalgia's sake. I began learning Common Lisp in Sep 2007 during a long layover at an airport using CLISP 2.41 on Debian 4.0 (Etch). Also, having another implementation helps me to test that my code is portable and does not rely on any SBCL-specific features.
https://marketplace.visualstudio.com/items?itemName=ailisp.c...
As a side note, this also means that Lisp programmers have been enjoying the functionality nowadays provided by LSP decades before it started being cool. :D
Introspection, graphical code navigation has been a thing in Apple MPW, Borland C++ for Windows, Visual Age for C++ (latter CSet++), C++ Builder, Eclipse, Visual Cafe, Visual Studio Enterprise.
Live debugging and recompilation, edit-and-continue in Visual Studio, JVM class reload capabilities and JRebel JVM agents.
REPLs, available as standard feature in Java since Java 9, prior to that there were IDE features like Eclipse Scrappages. Visual Basic interactive mode (classical VB), and nowadays F#, C# and VB.NET interactive shells on VS, including send-to-repl capability.
Lucid Energize C++ tooling from 1993 already enjoyed some of these features:
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B says: 27 years old. Not too shabby :-)
You should add refactoring capabilities for the C++/C#/Java tools to the list of features, I wonder how the Lisp stuff compares.
However the first refactoring tools appeared on Smalltalk, which is also a dynamic language, but it doesn't have macros and the image provides metadata that Lisps don't always have available.
But there are lots of examples where it really makes sense to be able to dispatch on multiple arguments. Arithmetic operations, for example. It's really nice to be able to add, say, arrays using the same syntax as adding numbers, or to be able to do array-array multiplication and array-scalar multiplication using the same syntax as multiplying numbers. Or, if you're doing graphics, to be able to specialize on both the object being drawn and the target to which it is being drawn.
There are loads of other things as well. The meta-object protocol allows you to do all kinds of wizzy things. Using EQL specialization lets you define special-case handling for a privileged object without cluttering up the rest of your code. BEFORE and AFTER methods let you tweak arguments on the way in or results on the way out.
Here's an example from a real-world project I'm working on: it's a 30-year-old legacy system and it's chock-full of hard-coded path names, literally thousands of them. We had to port it to a new environment where those paths don't exist. Normally this would have been a huge project to go through the source code and manually find and change all of the paths. Instead, I was able to define a BEFORE method on the OPEN function [1] which translated the incoming hard-coded path name to the correct value in the new environment. What would normally have been a multi-day headache was instead a five-minute tweak.
[1] Yes, I know OPEN is not actually a generic function, and so this is not actually possible in portable CL. But this was in ACL which provides this feature as an extension. And even in portable CL you can always shadow OPEN and redefine it. This is now getting away from the advantages of the OO system and into other parts of CL, but the bottom line is that many, many things that are a PITA in other languages are easy in CL.
[0]: https://en.wikipedia.org/wiki/Circle%E2%80%93ellipse_problem [1]: https://en.wikipedia.org/wiki/Expression_problem [2]: https://wiki.c2.com/?ExpressionProblem
No CL implementation I'm aware of follows this paradigm.
In most CL systems, image-based technically means it can dump memory to images on disk and start those. More exotic is nowadays, when quitting a Lisp system always writes all the changes to a new image, which then will be started next time.
ECL does not support images, but has live programming,
MOCL does not support images, nor full live programming. There are/were a bunch of CL compilers which work similar. They support then only a subset of CL - a subset without some runtime support for things like EVAL or COMPILE.
Typically non-image based and non-live Lisp compilers were written for the compilation of Lisp to C, with the purpose of generating small static executables, MOCL does that. MOCL is based on the earlier CLICC compiler.
In summary: I think SBCL is the most sophisticated Lisp compiler around and it is even free :). It is not as polished as some commercial solutions, which also come with IDEs, but in the setup of SBCL+Slime+Emacs, you have a professional Lisp setup which will go a long way. (I have done professional work with this setup).
Personally, I really like SBCL, it's my go-to implementation. I originally picked it because of performance considerations (hobby gamedev), as it compiles to native. But over time, I've learned to also appreciate the type inference and overall embracing the use of (optional by standard) type declarations to provide compile-time typechecking (as well as further performance benefits).
SBCL might be the best (in terms of correctness, adherence to the standard, performance of the compiled code, compatibility with existing libraries, tool support) open source compiler for CL. The compiler itself can be compared with commercial offerings (those seem to focus rather on additional libraries and external tools).
On ARM32 however, I do use CCL, as SBCL doesn't support multi-threading on that architecture.
I still find Lisp itself very hard to read, though. I understand the whole homoiconicity thing, and how S-expressions are one of the simplest implementations of that, but it's things like "car"/"cdr" instead of some reasonable memorable name (say, "first"/"rest") that kill me. Just don't seem to have the brain space for it.
--
SBCL is a compiler, it let's you use what was designed as an interpreted language, in an efficient, compiled way.
But this compiler has nothing to do with other compilers you probably know about. Instead of compiling the entire set, you just can compile fragments of code, or not compile them (interpret it for things like flexible self modifying code)if you want with total control.
Very very good for incremental programming, with tools like the REPL and debugging options you have nowhere else.
Having said that, I use my own dialect of Lisp in C, and I use that for writing code in the c world: c, c++, python, webasm, js.
I use SBCL only occasionally now.
SBCL has two compilation modes: a) compilation of source code files to machine code files
and b) compilation of Lisp expressions in memory.
a) can be used via the function COMPILE-FILE and b) typically via COMPILE (and thus also via EVAL)
Generally compilation of Lisp is nothing new (the first compiler was written in the early 60s) and the Common Lisp language definition (first in 1984) has many features to support Lisp compilation: compiler interface, code inlining, similar semantics for interpreted and compiled code, type annotations, ...
They are very different styles, though. With cl-who you write code that mimics the structure of HTML and that code outputs HTML. With Handlebars etc. you write your HTML in HTML and embed code in it. Some prefer one over the other.
It parses the HTML with embedded code, and generates a Lisp function which is compiled on the fly thanks to Lisp giving runtime access to the compiler. Whenever the source file is changed, the code is regenerated and compiled.
Other languages do the same, but in those cases they have to generate source code and call the compiler as an external program, and then load the generated code into the running program using dynamic linking. The Lisp approach is much more efficient.
Thanks to the quality of SBCL, the templates execute with native performance, which is something very few other solutions do.
The project is unfortunately not documented, but the code is available here: https://github.com/lokedhs/lofn
There's a third way, though: text templating libraries that support the full language. Does that exist for Common Lisp?
Hemlock is an Emacs, though, so I'm not really sure what it would bring.