5 ms·
Steel Bank Common Lisp
- larsbrinkhoff 9mo agoSBCL has been in the works since 1980.
- larsbrinkhoff 9mo agohttps://www.sbcl.org/history.html https://www.sbcl.org/history.html https://cmucl.org/doc/cmucl-history.html https://cmucl.org/doc/cmucl-history.html https://en.wikipedia.org/wiki/Spice_Lisp https://en.wikipedia.org/wiki/Spice_Lisp
- stassats 9mo agoStill 40 years to go.
- emptybits 9mo agoCan 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/ 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.
- tosh 9mo agonb: there is a SBCL release at end of every month: https://www.sbcl.org/all-news.html https://www.sbcl.org/all-news.html
- emptybits 9mo agoThanks. Your link gives more insight into "why submit now?" Appreciate it.
- deleted 9mo ago[deleted]
- dang 9mo agoWe upgraded to 2.6.1 about a week ago and switched to using the new(ish) parallel(ish) garbage collector. I still can't tell what the impact has been. Claude Code (which is a wizard at analyzing log files but also, I fear, an incorrigible curve-fitter) insisted that it was a real breakthrough and an excellent choice! On the other hand there was a major slowdown last night, ending in SBCL dying from heap exhaustion. I haven't had a chance to dig into that yet.
- stackghost 9mo ago>SBCL dying from heap exhaustion Due to hitting the cap, or to framentation? My understanding is the new parallel GC compacts the heap rather infrequently.
- dang 9mo agoIf by the cap you mean the heap size passed in as the --dynamic-space-size argument, it didn't hit the cap. It was using about 2/3 of that. > My understanding is the new parallel GC compacts the heap rather infrequently Can you explain more?
- stackghost 9mo agoI'm going to caveat this by stating up front that obviously HN's source code is not public so I don't know what your hot path looks like, and that I'm not a domain expert on garbage collection, but I do write a fair amount of lisp for SBCL. Immix-style collectors, like the new GC in SBCL, only compact on an opportunistic basis and so you get fragmentation pressure under load. In that situation, you might be well under the dynamic space size cap but if it can't find a large enough contiguous chunk of free heap it will still die. So, fragmentation would be my prime suspect given what you described.
- dang 9mo agoSorry for suddenly clinging to you for support but might we be better off using the older GC in that case?
- jibal 9mo agoWhat about it?
- oytis 9mo agoIt's a recurrent event when someone on HN discovers some well-known piece of technology.
- jjtheblunt 9mo agoagreed, but "tosh" posted numerous times on SBCL over the last 7 years, so it's a valid question. https://hn.algolia.com/?q=tosh+sbcl https://hn.algolia.com/?q=tosh+sbcl
- troad 9mo agoEh, let tosh have his/her fun. There's not so many submissions that it would qualify as spam, and SBCL is cool! A fun reminder of less majoritarian approaches to SWE. (Plus HN runs on it, so these threads often end up sparking some discussion of HN internals, which I think many of us enjoy.)
- jjtheblunt 9mo agoi enjoy the convos too.
- tmtvl 9mo agoIt's awesome and the lucky 10,000 deserve to be introduced to it?
- mikestorrent 9mo agoA well known quantum computing company's entire stack runs on SBCL, with Emacs in production... works really well, don't knock it until you've tried it. Phenomenal REPL.
- 9mo ago
- shadowgovt 9mo agoMy favorite bit of SBCL trivia is the name: this is descended from Carnegie Mellon's build. Steel. Bank.
- wiz21c 9mo agoI don't get it :-(
- wk_end 9mo agoI think it's just that Andrew Carnegie made his fortune in the steel industry, and the Mellons made their fortune in banking.
- PantaloonFlames 9mo agoYes and Carnegie Technical Schools was founded in 1900 based on a $1m donation from Andrew Carnegie, Mellon Institute of Industrial Research was originally founded in 1913 by Andrew and Richard Mellon. Carnegie Mellon was created by combining the two institutions in 1967.
- giraffe_lady 9mo agoThat's very fun and makes so much more sense than my half guess that it was from a defunct regional mid 20th century bank I had never heard of.
- christophilus 9mo agoYou're not alone. TIL.
- ethagnawl 9mo agoWow. I'd always thought/assumed the S was in reference to (Guy) Steele.
- philipkglass 9mo agoOlder 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: https://news.ycombinator.com/item?id=41679215 https://news.ycombinator.com/item?id=41679215 [1] https://paulgraham.com/arc.html https://paulgraham.com/arc.html [2] https://racket-lang.org/ https://racket-lang.org/
- rayiner 9mo agoI love this comment: "Btw, we rolled this out over 3 weeks ago and I think you're the first person to ask about it on HN. There was one earlier question by email. I think that qualifies as a splash-free dive." I had no idea and I'm an HN addict!
- philipkglass 9mo agoI was the person who emailed him about it earlier. 2024-09-05, me: On another topic, I just noticed that the 700+ comments on https://news.ycombinator.com/item?id=41445413 https://news.ycombinator.com/item?id=41445413 all render on a single page. Hurray! Is the pagination approach obsolete now? I know that you've commented several times about wanting to optimize the code so pagination wasn't necessary. I don't know if that's finished or if pagination will have to go on the next time there's a big breaking story. Dan G: Yes: the performance improvements I've been working on for years finally got deployed, so pagination is turned off for now. (In case you're curious, the change is that Arc now runs over SBCL instead of Racket.) ... Btw you're the only person I know of who's noticed this and pointed it out so far! I have very mixed feelings about how much I know about this site.
- dang 9mo agoThe "splash-free dive" metaphor came from the greatly missed sctb and was the springboard for much fun conversation at HNHQ. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20splash%20free&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- pjmlp 9mo agoWhile great option, LispWorks and Allegro Common Lisp should not be overlooked, too many focus on SBCL + Emacs and then complain about Lisp tooling.
- cultofmetatron 9mo ago> too many focus on SBCL + Emacs and then complain about Lisp tooling. well yea, lispworks and allegro are expensive commercial projects. I wish sbcl, the defacto best open source option had better tooling. emacs is great and all for the true believers but I'm an unwashed vscode user. For plenty of reasons I can't justify it in my startup but I'd love to spend more time working with common lisp for personal projects but my time is limited so I prefer clojure or rust.
- pjmlp 9mo agoThey have community editions.
- vindarel 9mo agoI can't load my side projects in LispWorks' community edition, so… (because of the heap limit)
- dmpk2k 9mo agoVaguely related, but have you tried Alive? https://marketplace.visualstudio.com/items?itemName=rheller.alive https://marketplace.visualstudio.com/items?itemName=rheller....
- stackghost 9mo agoI use emacs regularly (in fact I have it running right now) and I think the complaints against it are perfectly valid. Emacs is awesome in lots of ways, but it also really, really sucks in lots of other ways. But putting emacs aside, the SBCL tooling seems reasonable to me. The real reason I rarely reach for lisp these days is not the tooling, but because the Common Lisp library ecosystem is a wasteland of partial implementations and abandoned code bases. It's also been my experience that LLMs are better at writing more mainstream languages, especially "newbie-proof" languages like Go. In any case, I don't see why one would reach for Allegro or Lispworks over SBCL unless one really enjoys writing lisp by hand and needs specific features they offer that SBCL doesn't. I would imagine those features are vanishingly few.
- umairnadeem123 9mo ago[dead]
- iberator 9mo agoHow come it is named like that? It's a product of some old school consortium? I know that ford,gm etc also made some R&D into software
- kej 9mo agoFrom the About page: >SBCL derives most of its code from CMU CL, created at Carnegie Mellon University. Radical changes have been made to some parts of the system (particularly bootstrapping) but many fundamentals (like the mapping of Lisp abstractions onto the underlying hardware, the basic architecture of the compiler, and much of the runtime support code) are only slightly changed. Enough changes have been made to the interface and architecture that calling the new system CMU Common Lisp would cause confusion - the world does not need multiple incompatible systems named CMU CL. But it's appropriate to acknowledge the descent from the CMU hackers (and post-CMU CMU CL hackers) who did most of the heavy lifting to make the system work. So the system is named Steel Bank after the industries where Andrew Carnegie and Andrew Mellon, respectively, made the big bucks.
- p_l 9mo agoIn addition to the official reference to CMU, there is a second origin for the name. SBCL - Sanely Bootstrappable Common Lisp You see, when SBCL was forked from CMU, a major effort was done so that it could be compiled using any reasonably complete Common Lisp implementation, unlike CMU CL. Because CMU CL essentially could only be compiled by itself, preferably in the same version, which meant compiling and especially cross-compiling was complex process that involved bringing the internal state of CMUCL process to "new version". SBCL redid the logic heavily into being able to host the core SBCL compiler parts in any mostly-complete (does not have to be complete!) ANSI CL implementation, then uses that to compile the complete form. Meaning you can grab SBCL source tarball, plus one of GNU clisp, ECL, Clozure CL, even GNU Common Lisp at one point, or any of the commercial implementations, including of course CMUCL, and C compiler (for the thin runtime support) and build a complete and unproblematic SBCL release with few commands
- moonlion_eth 9mo agocommon lisp is the one true language
- vincent-manis 9mo agoIf I couldn't have Scheme, I'd happily take CL.
- ivanb 9mo agoIt 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.
- reikonomusha 9mo agoCoalton [1] adds Haskell-style types (so typed lists, type classes, parametric polymorphism, ...) to Common Lisp, and compiles to especially efficient code in SBCL. [1] https://coalton-lang.github.io/ https://coalton-lang.github.io/
- ivanb 9mo agoCoalton is nice but it requires a wrapper around every form you feed a REPL or around the whole file. If on the other hand SBCL had a more powerful type system or extension points for a pluggable type system...
- 9mo ago
- ivanb 9mo agoHijacking the thread, the JetBrains plugin for Common Lisp had not been maintained since 2023. I forked it and vibed it back to life. You don't need Emacs. Feel free to enjoy Common Lisp in your regular IDE. https://github.com/ivanbulanov/SLT/releases https://github.com/ivanbulanov/SLT/releases
- atilaneves 9mo ago> You don't need Emacs Yes, I do.
- uhoh-itsmaciek 9mo agoThe program with possibly my favorite error message: https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/src/runtime/interrupt.c#l2184 https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/src/runti...
- eigenspace 9mo agoI 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.