6 ms·

SBCL is an implementation of Common Lisp with a long and rich history (if you include CMUCL as a part of that history). It’s an implementation that sees regular

SBCL is an implementation of Common Lisp with a long and rich history (if you include CMUCL as a part of that history). It’s an implementation that sees regular contributions from random travelers, and the team of regular developers (if you can even call them a “team”) is small and loosely knit but surprisingly steady. There’s a trusted set of individuals with commit privileges and many of them hack and improve SBCL just about every day. Some of the regular devs are new with their first commits clocking in less than 6 months ago, and others are long retired, having moved on to other things beyond SBCL. SBCL is a piece of software that’s not inundated with opinions, politics, drama, and other organizational issues. That is in part due to the fact that the folks who develop it must stay grounded. ANSI Common Lisp is, well, a standardized language and the SBCL aims to follow it to a tee. SBCL is just a small-town coffee shop compared to the Starbucks and Dunkin Donuts of other language implementations. As a professional and commercial user of their software, the size of the user base and developer team used to worry me. But 20 years of stability—compared to even the most contemporary language ecosystems—has given me solace in my choice to use it.

cheez 7y ago
Interesting. I suppose you use it for servers and you don't deploy SBCL to end-user machines?
- reikonomusha 7y ago
  It is deployed to end-user machines. [0] It’s also open source. [1,2] [0] https://www.rigetti.com/forest https://www.rigetti.com/forest [1] https://github.com/rigetti/qvm https://github.com/rigetti/qvm [2] https://github.com/rigetti/quilc https://github.com/rigetti/quilc
  - cheez 7y ago
    Really cool!
  - 7thaccount 7y ago
    Very neat! Any blog post on why you chose Common Lisp? I assume you wanted to build your own DSL with macros, but several other tools can do this (Smalltalk, Clojure, Racket, Chez Scheme, Julia... etc). I like CL and think it is as good a choice as any, but what made you decide to use it over some other options?
    - reikonomusha 7y ago
      Not yet. Hopefully one coming soon!
      - 7thaccount 7y ago
        I look forward to it. Do you have a favorite article on Quantum Computing for Dummies? How they work, what problems they're good at...etc. I'm sure many many exist, but I figure you have one you point people towards.
- pcr910303 7y ago
  > I suppose you use it for servers and you don't deploy SBCL to end-user machines? AFAIK, most Common Lisp applications are deployed in a single binary, bundled with the lisp implementation. SBCL isn’t an exception, so if someone would deploy an SBCL app to end-users, one would build a self-contained application with the `sb-ext:save-lisp-and-die` function [0]. [0]: https://lispcookbook.github.io/cl-cookbook/scripting.html https://lispcookbook.github.io/cl-cookbook/scripting.html
  - codr7 7y ago
    This feature is a godsend when implementing your own language [0] on top since everything is wired up automatically when the application starts. Compared to emitting C or whatever where you need to include code to stitch the runtime state together. Makes compiling standalone executables so easy [1] it feels like cheating. [0] https://github.com/codr7/lila https://github.com/codr7/lila [1] https://github.com/codr7/lila/blob/master/main.lisp https://github.com/codr7/lila/blob/master/main.lisp
  - cheez 7y ago
    I never managed to get SLAD to work with Qt bindings and stuff. CL was my preference many years back, but practical usage at the fringes required me to be a SBCL expert. Sadly, I am/was not :-( so now I am a Python Pleb.
- mark_l_watson 7y ago
  It is easy to make one file executables that handle command line arguments, offer a web or local UI, etc. And apps start instantly.
pjmlp 7y ago
Still I think it could be much better with the graphical tooling of the surviving commercial Lisps.
- reikonomusha 7y ago
  No doubt about that! LispWorks and Franz Inc offer great products in this arena.
- TurboHaskal 7y ago
  I ended up buying LispWorks for that reason, and after putting up the work and reading the documentation I found out I am more productive with their IDE than with Slime. That being said, I am so dependent on SBCL's treatment of types that I always have a Slime session open in order to parallely develop non graphical code on both. It is truly an amazing implementation. Here’s to another 20 years and beyond!
  - _pmf_ 7y ago
    I think a lot of people would be interested in reading more about your workflow.
    - TurboHaskal 7y ago
      Nothing to write home about. Most of the time I'm developing inside of LispWorks, but because I'm so used to Emacs and I'll be using org-mode and magit anyway, having a Slime session as well to try out stuff and run tests comes at no cost. Simply compiling something with SBCL catches some stuff, and it's always good to make sure your code works in different implementations during actual development and not as an afterthought. Besides, as clunky/spartan as they are, Slime and Sly are a lot of fun so why not? Even good old Hemlock gets some use. When developing I always detach the UI code so it lives in its own package, where I don't hesitate to make use of implementation goodies such as CAPI (of course) and the mp package. The rest of the stuff aims to be portable CL and uses the de-facto compatibility libraries.
  - mmargerum 7y ago

cheez 7y ago

Interesting. I suppose you use it for servers and you don't deploy SBCL to end-user machines?

reikonomusha 7y ago
It is deployed to end-user machines. [0] It’s also open source. [1,2] [0] https://www.rigetti.com/forest https://www.rigetti.com/forest [1] https://github.com/rigetti/qvm https://github.com/rigetti/qvm [2] https://github.com/rigetti/quilc https://github.com/rigetti/quilc
- cheez 7y ago
  Really cool!
- 7thaccount 7y ago
  Very neat! Any blog post on why you chose Common Lisp? I assume you wanted to build your own DSL with macros, but several other tools can do this (Smalltalk, Clojure, Racket, Chez Scheme, Julia... etc). I like CL and think it is as good a choice as any, but what made you decide to use it over some other options?
  - reikonomusha 7y ago
    Not yet. Hopefully one coming soon!
    - 7thaccount 7y ago
      I look forward to it. Do you have a favorite article on Quantum Computing for Dummies? How they work, what problems they're good at...etc. I'm sure many many exist, but I figure you have one you point people towards.
pcr910303 7y ago
> I suppose you use it for servers and you don't deploy SBCL to end-user machines? AFAIK, most Common Lisp applications are deployed in a single binary, bundled with the lisp implementation. SBCL isn’t an exception, so if someone would deploy an SBCL app to end-users, one would build a self-contained application with the `sb-ext:save-lisp-and-die` function [0]. [0]: https://lispcookbook.github.io/cl-cookbook/scripting.html https://lispcookbook.github.io/cl-cookbook/scripting.html
- codr7 7y ago
  This feature is a godsend when implementing your own language [0] on top since everything is wired up automatically when the application starts. Compared to emitting C or whatever where you need to include code to stitch the runtime state together. Makes compiling standalone executables so easy [1] it feels like cheating. [0] https://github.com/codr7/lila https://github.com/codr7/lila [1] https://github.com/codr7/lila/blob/master/main.lisp https://github.com/codr7/lila/blob/master/main.lisp
- cheez 7y ago
  I never managed to get SLAD to work with Qt bindings and stuff. CL was my preference many years back, but practical usage at the fringes required me to be a SBCL expert. Sadly, I am/was not :-( so now I am a Python Pleb.
mark_l_watson 7y ago
It is easy to make one file executables that handle command line arguments, offer a web or local UI, etc. And apps start instantly.

pjmlp 7y ago

Still I think it could be much better with the graphical tooling of the surviving commercial Lisps.

reikonomusha 7y ago
No doubt about that! LispWorks and Franz Inc offer great products in this arena.
TurboHaskal 7y ago
I ended up buying LispWorks for that reason, and after putting up the work and reading the documentation I found out I am more productive with their IDE than with Slime. That being said, I am so dependent on SBCL's treatment of types that I always have a Slime session open in order to parallely develop non graphical code on both. It is truly an amazing implementation. Here’s to another 20 years and beyond!
- _pmf_ 7y ago
  I think a lot of people would be interested in reading more about your workflow.
  - TurboHaskal 7y ago
    Nothing to write home about. Most of the time I'm developing inside of LispWorks, but because I'm so used to Emacs and I'll be using org-mode and magit anyway, having a Slime session as well to try out stuff and run tests comes at no cost. Simply compiling something with SBCL catches some stuff, and it's always good to make sure your code works in different implementations during actual development and not as an afterthought. Besides, as clunky/spartan as they are, Slime and Sly are a lot of fun so why not? Even good old Hemlock gets some use. When developing I always detach the UI code so it lives in its own package, where I don't hesitate to make use of implementation goodies such as CAPI (of course) and the mp package. The rest of the stuff aims to be portable CL and uses the de-facto compatibility libraries.
- mmargerum 7y ago