Fantastic implementation - rock solid. It does feel like the OS X version trails the rest of the platforms, is that true ? It hasn't mattered much for the work I've done with it but curious.
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.
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?
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.
> 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].
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.
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.
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.
I think they are missing an opportunity there. The commercial prices are in line with other professional software offerings. But as a hobbyist I never could quite convice myself to buy a license. As nice as their environment is, there is SBCL. Consequently, at work I would use SBCL too and not argue for a Lispworks license. Of course, while lacking the IDE, SBCL is likely the better Lisp compiler.
Well there's more to it than just the compiler, but if you develop for the server and either SBCL or CCL are behaving like champs for your needs, there aren't many reasons to change. The IDE is really nice but it isn't a game changer. LispWorks shines when you have to ship products that customers will run themselves.
As for the pricing of the Hobbyist edition, I think they are hurting their business this way in the long term. Times have changed and thanks to Quicklisp the ecosystem is better and more important than ever, but a lot of libraries go untested for LW because of such paywall. Not to mention the Personal Edition is barely usable and leaves a bad impression.
But then again, these are just my two cents. I am not going to tell one of the very few commercial vendors alive today how to run their business.
I have to agree. I am using SBCL for all of my Common Lisp work and highly appreciate it. I am able to fulfil my graphical tooling needs with LTk, but I think SBCL would have gained by officially adopting one of the available UI libraries and consequently offering more GUI tools out of the box.
But being as it is, it is easy to load a GUI library of your choice and as a Lisp implementation SBCL is just great.
SBCL purposefully dropped many "extra" libraries that were part of CMU (including GUI library) in order to focus on the lisp implementation itself. Given that the "missing" libraries are recouped by often better external code these days, I find it a pretty good option.
Unfortunately probably nobody has time to work on LW-level GUI library. Significant effort involved from people who mostly have no need for one.
You are probably talking about clx. When talking about GUI libraries, I was more thinking about high-level libraries, which for example bind to Gtk, Qt or Tk. There are plenty of those libraries, and that is good. But I would have liked, if the SBCL maintainers had worked together with one of the maintainers of those libraries with the goal of eventually distributing it with SBCL. So there would be a default library to target when developing tools like e.g. a graphical debugger.
Today, quicklist solves a lot of dependency problems, but having an "official" GUI library could have stimulated development of more UI tools around SBCL.
SBCL is amazing. If you walk the development history back trough forks, organizations and names the starting point is Spice Lisp[1] in 1980, then CMUCL in 1985 and finally SBCL in 1999.
I've used SBCL regularly since the initial announcement, truly an excellent piece of software that only keeps getting better.
Being able to sit back and watch bug fixes and performance improvements trickle in without having to deal with the usual torrent of new/deprecated features is a nice change from other languages.
Using implementation-specific features is mostly frowned upon in the CL community, but SBCL is so rock-solid and readily available that I feel less and less motivated to deal with cross-implementation issues. Much like GHC in Haskell land.
SBCL is great. I do think it would be a significant improvement to include a fuller featured terminal REPL out of the box (with history, s-exp editing keystrokes, completion), and that this would make a better first impression on new users experimenting with the language, before they've given in and installed SLIME - and probably beneficial for the crowd that wants to use their favorite editor rather than Emacs+SLIME, insomuch as they only need to solve the problem of getting definitions reloaded from the editor, without having to also reinvent slime-repl, inspector, debugger, etc.
33 comments
[ 5.6 ms ] story [ 91.1 ms ] thread[1] https://portacle.github.io
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.
[0] https://www.rigetti.com/forest
[1] https://github.com/rigetti/qvm
[2] https://github.com/rigetti/quilc
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
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
[1] https://github.com/codr7/lila/blob/master/main.lisp
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.
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!
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.
As for the pricing of the Hobbyist edition, I think they are hurting their business this way in the long term. Times have changed and thanks to Quicklisp the ecosystem is better and more important than ever, but a lot of libraries go untested for LW because of such paywall. Not to mention the Personal Edition is barely usable and leaves a bad impression.
But then again, these are just my two cents. I am not going to tell one of the very few commercial vendors alive today how to run their business.
But being as it is, it is easy to load a GUI library of your choice and as a Lisp implementation SBCL is just great.
Unfortunately probably nobody has time to work on LW-level GUI library. Significant effort involved from people who mostly have no need for one.
[1]: See page 58 in Performance and evaluation of Lisp systems by Richard Gabriel http://rpgpoet.com/Files/Timrep.pdf
Being able to sit back and watch bug fixes and performance improvements trickle in without having to deal with the usual torrent of new/deprecated features is a nice change from other languages.
Using implementation-specific features is mostly frowned upon in the CL community, but SBCL is so rock-solid and readily available that I feel less and less motivated to deal with cross-implementation issues. Much like GHC in Haskell land.
Keep it up!
Also, Portacle [1] is a SBCL + (Emacs based) IDE distro that's super easy to setup and use.
[1] https://portacle.github.io
I still use Windows and sometimes the machines I'm working on don't have dev environment to build SBCL.