Can we get a "(1999)" date on this, please? Only half joking becuase I see Common Lisp and, sure, I upvote ... but honestly, what's the purpose of this HN submission without context?
SBCL is obviously fantastic but let's contrast with another popular implementation: Embeddable Common Lisp. https://ecl.common-lisp.dev/
Top marks for SBCL performance but ECL can be a better fit for embedding into mobile applications, running on lighter weight hardware, and in the browser.
Older HN users may recall when busy discussions had comments split across several pages. This is because the Arc [1] language that HN runs on was originally hosted on top of Racket [2] and the implementation was too slow to handle giant discussions at HN scale. Around September 2024 Dang et al finished porting Arc to SBCL, and performance increased so much that even the largest discussions no longer need splitting. The server is unresponsive/restarting a lot less frequently since these changes, too, despite continued growth in traffic and comments:
It is probably the best Common Lisp compiler when it comes to type checking. However, it leaves a lot to be desired. For example, it cannot specialize an element type for lists. With lists being the go-to structure, if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python.
The ability to specialize list parameter types would greatly improve type checking. It would also help the compiler to optimize lists into unboxed arrays.
Please don't tell me that static type checking doesn't lend itself to CL. The ship has sailed. It does work with SBCL rather well, but it can be better.
Some may blame the Common Lisp standard. It indeed doesn't specify a way for list specialization, but the syntax is extensible, so why not make it as a vendor extension, with a CDR? AFAIK CDR was supposed to be to Common Lisp what PEP is to Python.
I would use vectors and arrays, but in CL ergonomics is strongly on the side of lists. For short structures vectors and arrays don't make sense.
I think it is also a time to outgrow the standard and be more brave with extensions. A lot has changed since the standard. It is still very capable, but as powerful as CL is, some things just cannot be practically implemented in the language and have to be a part of the runtime. Yes, I'm talking about async stuff.
So I got the idea to see how difficult it would be to bolt on async runtime to SBCL. To my surprise the project is hosted on awfully slow SourceForge and project discussions are still happening on mailing lists. Sorry, but I am too corrupted by GitHub's convenience.
I didn't use Common Lisp for very long, but unbeknownst to me at the time, getting interested in (SB)CL was a bit of a turning point for me from being primarily interested in physics to being interested in programming and software development.
During my physics undergrad, I was pretty uninterested in programming and I was only interested in "pen-and-paper" physics. Numerical solutions weren't very intellectually interesting to me. I knew a bit of Matlab, Python, and Mathematica, but of those languages only Mathematica was remotely intriguing to me, but I ran into some contexts already where all the above languages where just too slow to solve some important problems.
I spent the summer before my Masters degree started trying to decide on what language I should learn and master, I didn't want to have this annoying situation where I had to mix and match between slow expressive languages and fast, clunky languages.
I almost went for Fortran, but then I happened upon some old threads about Common Lisp, and people discussing some concepts I wasn't really familiar with like metaprogramming and I got quite intrigued. Metaprogramming was the first software topic that I found intellectually stimulating in its own right. Before that, programming was just a means to an end for me.
I spent a couple months reading old Common Lisp books and learning to use it, before I then stumbled upon Julia, and found that it had just about everything I was looking for -- an active scientific community, expressiveness, performance, interesting metaprogramming facilities.
At that point, I pretty much stopped all my common lisp usage in favour of Julia, and still heavily use Julia to this day in my job as a software developer, but I credit Common Lisp (and SBCL in particular) with being the thing that actually convinced me that there was something interesting about programming in its own right.
14 comments
[ 4.4 ms ] story [ 32.9 ms ] threadSBCL is obviously fantastic but let's contrast with another popular implementation: Embeddable Common Lisp. https://ecl.common-lisp.dev/
Top marks for SBCL performance but ECL can be a better fit for embedding into mobile applications, running on lighter weight hardware, and in the browser.
Steel. Bank.
https://news.ycombinator.com/item?id=41679215
[1] https://paulgraham.com/arc.html
[2] https://racket-lang.org/
I know that ford,gm etc also made some R&D into software
The ability to specialize list parameter types would greatly improve type checking. It would also help the compiler to optimize lists into unboxed arrays.
Please don't tell me that static type checking doesn't lend itself to CL. The ship has sailed. It does work with SBCL rather well, but it can be better.
Some may blame the Common Lisp standard. It indeed doesn't specify a way for list specialization, but the syntax is extensible, so why not make it as a vendor extension, with a CDR? AFAIK CDR was supposed to be to Common Lisp what PEP is to Python.
I would use vectors and arrays, but in CL ergonomics is strongly on the side of lists. For short structures vectors and arrays don't make sense.
I think it is also a time to outgrow the standard and be more brave with extensions. A lot has changed since the standard. It is still very capable, but as powerful as CL is, some things just cannot be practically implemented in the language and have to be a part of the runtime. Yes, I'm talking about async stuff.
So I got the idea to see how difficult it would be to bolt on async runtime to SBCL. To my surprise the project is hosted on awfully slow SourceForge and project discussions are still happening on mailing lists. Sorry, but I am too corrupted by GitHub's convenience.
You don't need Emacs. Feel free to enjoy Common Lisp in your regular IDE.
https://github.com/ivanbulanov/SLT/releases
During my physics undergrad, I was pretty uninterested in programming and I was only interested in "pen-and-paper" physics. Numerical solutions weren't very intellectually interesting to me. I knew a bit of Matlab, Python, and Mathematica, but of those languages only Mathematica was remotely intriguing to me, but I ran into some contexts already where all the above languages where just too slow to solve some important problems.
I spent the summer before my Masters degree started trying to decide on what language I should learn and master, I didn't want to have this annoying situation where I had to mix and match between slow expressive languages and fast, clunky languages.
I almost went for Fortran, but then I happened upon some old threads about Common Lisp, and people discussing some concepts I wasn't really familiar with like metaprogramming and I got quite intrigued. Metaprogramming was the first software topic that I found intellectually stimulating in its own right. Before that, programming was just a means to an end for me.
I spent a couple months reading old Common Lisp books and learning to use it, before I then stumbled upon Julia, and found that it had just about everything I was looking for -- an active scientific community, expressiveness, performance, interesting metaprogramming facilities.
At that point, I pretty much stopped all my common lisp usage in favour of Julia, and still heavily use Julia to this day in my job as a software developer, but I credit Common Lisp (and SBCL in particular) with being the thing that actually convinced me that there was something interesting about programming in its own right.