I use Common Lisp for most of my daily programming, and SBCL is a big reason why. Once you get over the initial hassle (getting used to the Emacs+SLIME tool chain and learning to read the compiler diagnostics) it really gives you the productivity of Python with the performance of C++. And a lot of that performance is thanks to the tireless effort of the SBCL developers, who have been churning out a new release every few months for the last decades.
I work in academia. My research is about new concepts for parallel programming, especially via runtime optimization and JIT compilation. It was not hard to convince others to use Common Lisp for this - there aren't many languages that allow for metaprogramming at run time. And of these languages, Common Lisp is the only one with decent performance.
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.
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.
Swank/Slynk clients are generally preferable to LSP clients when doing Common Lisp. LSP infrastructure in Lisp (notably, the cl-lsp library) is relatively young and not widely used, whereas Slime/Swank is thoroughly battle-tested because it has been widely used years before LSP has been created.
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
I know about Smalltalk, but I didn't know about Java and .NET! Could you point me to utilities for those languages that allowed for features like autocompletions, introspection, live debugging, recompilation, REPLs - standard stuff in Slime/Swank?
autocompletions have been a feature in IDEs since Visual C++ was introduced, and copied by Java IDEs, and naturally Visual Studio for .NET languages as well.
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:
Yeah, due to dynamic types is might do well than C++/C#/Java refactoring tools.
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.
This is what I've been using to learn CL. It's a very small barrier to entry compared to when I've tried (and failed) in the past to approach Lisp from Emacs.
Yes, I use it professionally, and have for over 30 years, since before it became Common Lisp. It is far and away my favorite programming language (hence my HN handle :-) for two reasons: macros allow me to capture any design pattern and seamlessly add it to the language as a programming construct, and the generic function model of OO built in to CL is vastly more powerful than the C-based single-dispatch object.method() model that is ubiquitous in the rest of the programming language world.
The big win is not so much in the actual underlying power, but rather in the syntactic uniformity. In traditional OO languages there is a semantic difference between f(arg1, arg2) and arg1.f(arg2) and as a programmer I have to remember which one is the right one for any particular operation I want to do. In CL the syntax for a regular function call and a generic function call is exactly the same, so as a programmer I don't have to worry about it. I just write (do-something arg1 arg2) and let the compiler figure it out. It removes a tremendous amount of cognitive burden.
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.
I like the Circle-Ellipse Problem [0] as an example of something CLOS / multimethods are good at that C++ isn't. In general, Expression Problem-like [1, 2] problems are much much nicer to solve in CL.
I use it to write the star-mapping software behind https://greaterskies.com many years ago. I did it as a fun project after reading PG's essays, but now it is supporting my family and two employees. In the few occasions I need to touch something or add a new feature I feel like coming back home.
I have never written it down, but it's very simple. I don't use any external libraries. I converted the input databases to lisp and compiled them in, and the output is simple postscript. When I want to deploy I dump a core with the compiled functionality, then run sbcl with that core. At some point I was using hunchentoot[1] to provide an http point of entry (great library, as all the ones written by Edi Weitz) but I am not bothering anymore, as most of the processing time is consumed by ghostscript and convert in the post-processing of the images.
Yes, I use SBCL daily. The fact that SBCL (like most CL implementations) is image-based makes CL the language for interactive and incremental programming and live debugging the program as it runs. (Shameless plug: I wrote a book about the last point and about how CL achieves it. https://www.apress.com/us/book/9781484261330)
In theory, a Common Lisp implementation is not required to be image-based. The standard permits a Common Lisp compiler that can e.g. be a batch file compiler that turns files into binaries, and then those can be executed without lots of live-programming, image-based goodies.
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.
I do. Feel free to ask any questions, I will try to answer them if possible.
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).
I do. Currently only in hobby fashion, but I also used it professionally when contracting for a company that was building a computation-intensive web platform on a Common Lisp (SBCL) backend. AMA.
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).
I use Common Lisp for 'exploratory computing' as they say. It's my go-to language if I want to quickly evaluate an idea. Took me a while to learn, but since acquiring at least modest familiarity, I have less patience with ad-hoc syntax (syntactic sugar) found in in-fix languages and the churn found in many currently popular languages.
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.
SBCL is one of those exceptional free software projects IMO. It's compiler which includes type inference and optimizations is world-class among Common Lisp implementations.
SBCL is a "sufficiently smart" compiler, that makes Lisp fast. I've replaced enough software with CL, that now I can't stand to use a computer without it. With CL you can do whatever the fuck you want, all the time. It's glorious. The limitations are your own ability, and having to interface to crappy non-CL software, idiotic non-Lisp protcols, and hardware seemingly designed to be operated by spavined brine shrimp. But also I'm "eccentric" and I like exiling myself to the software wilderness, where you have great freedom, but have to be very self reliant.
I don't write Lisp myself, but I support SBCL-based apps running in production, and it's a very interesting beast. The REPL and the debugger/inspector are amazingly powerful.
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.
FWIW, "first" and "rest" are literally aliases for "car" and "cdr" (and there's a bunch more, see [0]), so it may be that the code you're working with isn't following a good style. The general style rule for more modern code is that you use "first"/"rest" if you're dealing with regular lists, and "car"/"cdr" if you're doing something more peculiar with cons cells - though it's not universally followed, and I guess at this point "car"/"cdr" & friends are too established in the history of Lisp.
I've done quite a bit of Scheme in the past, but I've been playing with Common Lisp a little recently, and I often find myself thinking things like "how do I convert a string to a list of characters" or "how do I check if this thing is in this list", like simple standard library stuff that I could implement myself but expect to already be there, and then I go look in the Hyperspec, and sometimes it's hard to find thing when you don't have a name to look up.
For me learning Lisp is an essential requirement for becoming a professional programmer, even if you don't use it after that, you will "Lispify" everything you touch. It just changes the way you think.
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.
SBCL was for years a compilation only Lisp implementation. A few years ago an interpreter for Lisp was added, but is not used by default.
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, ...
I do, this year I shipped a web application and paid a few rents with it. It reads an existing DB, fetches data from a SOAP service, sends daily reports to a FTP server and renders some HTML templates. I'm coming from Python and am much happier now. The compile-time checks and the deployment stories are particularly appreciated.
Just started learning Lisp (Emacs Lisp), and I am planning on doing a deep dive in Common Lisp. Using Python and Pandas for my day to day scripting. Common Lisp does not have the ecosystem in terms of packages compared to Python (or JS / NodeJS), but hacking Lisp feels extremely good. I intend to use it for prototyping, for all kinds of hacking that does not involve using available packages.
