* the SB-SIMD contrib now supports ARM64. (Thanks to Sylvia Harrington) * AVX512 instructions are now supported on X86-64. (Thanks to Robert Smith and Arthur Miller) * additional support for SIMD instructions on ARM64 and X86-64. (Thanks to Arthur Miller) These seem like pretty awesome additions. Does anyone know how SIMD works in SBCL? Is this at the codegen layer? i.e. can it auto-vectorize or anything like that? O…
No auto-vectorization yet, but you may find this illuminating: https://www.stylewarning.com/posts/nbody
Steel Bank Common Lisp version 2.6.7
51–60 of 172 posts
Re: Steel Bank Common Lisp version 2.6.7
#52Fun fact I learned from a Func Prog podcast: the name Steel Bank is a play on it's origin as Carnegie-Mellon Common Lisp (Carnegie made his fortune in Steel, while Mellon did so with Banks): https://www.sbcl.org/history.html
Namely, that "SB" stands for "Sanely Bootstrappable" - something that the CMU Common Lisp was unable to do
Re: Steel Bank Common Lisp version 2.6.7
#53Earlier quoted context omitted.
> The very power of Lisp, macros, dynamic programming, reflection lead to a mess of an ecosystem where every single developer reinvents the wheel and nobody can understand yet another DSL invented by the next developer next to them. Have you like looked at anything in the Clojure ecosystem because this description makes no sense of any kind. Clojure has macros but less powerful than common lisp and Clojure code in th…
It seems to me the Clojure community internalized the lesson of not writing macros unless it's really necessary more than other Lisps did.
Re: Steel Bank Common Lisp version 2.6.7
#54If memory serves, traditionally, CCL (Clozure Common Lisp [0]) had better support for Windows but SBCL was unbeatable for speed. Is that still the case? [0] https://ccl.clozure.com/
Re: Steel Bank Common Lisp version 2.6.7
#55I wonder sometimes how the world would look like if lisp won and the unit of deployment was a lisp machine image, if that makes sense. How would a kubernetes optimized for lisp look like? How would AWS EC2 look like? etc.
That (deployment is via a customized image) is the thing I find most awkward. Somewhere, I have a copy of a commercial LISP for Windows which would compile to an executable --- apparently this sort of thing is still possible, but it's not widely known/used, and sadly Jean-Marie Hullot's "SOS Interface" for the Mac was co-opted to NeXTstep: https://denninginstitute.com/itcore/userinterface/GUIHistory... I'd dearly lov…
Re: Steel Bank Common Lisp version 2.6.7
#56Earlier quoted context omitted.
>FWIW, at a FAANG! Do you work on ITA? Only FAANG I'm aware of using Lisp is Google.
Nope not on ITA. I work at the intersection of HW and SW. Lisp is valued for its strengths and I haven't come across any tool better to explore complex problem space. Of course, the opportunities are fewer, get filled up organically and are better suited for someone with valuable domain knowledge who can translate it into working space for a wider team using Lisp as the tool to write the spec!
Re: Steel Bank Common Lisp version 2.6.7
#57I wonder sometimes how the world would look like if lisp won and the unit of deployment was a lisp machine image, if that makes sense. How would a kubernetes optimized for lisp look like? How would AWS EC2 look like? etc.
Re: Steel Bank Common Lisp version 2.6.7
#58Earlier quoted context omitted.
CL can be used pretty much anywhere nowadays, even on the web with ECL wasm compilation.
Anywhere is where exactly? I've been thinking of where I could use it for like 10 minutes, and I couldn't come up with anything. Maybe a game engine or web services. It wouldn't make much sense for any kind of desktop software or command line utilities that are supposed to start really fast and have minimal runtime.
Web services need either cooperative concurrency or M:N concurrency due to the "10k problem". CL only supports threads (OS-level) and promises; everything else is incomplete (eg., delimited continuations, which could be used to build coroutines) due to missing parts in the spec and some language features (eg., conditions and restarts). Of course it can be done, but it won't be as pleasant as using Elixir and Phoenix.
A game engine would work, most likely, unless it was for an MMO (again, concurrency handling). I personally never worked on one, but I see examples of game engines in CL, and they tend to look nice.
In general, single-user desktop (CLI, TUI, GUI) apps are still a good fit for CL, even today (you need to put some work into packaging the app for different platforms, but it tends to be easier to set up than it is for C or C++; harder than Go or Rust, though). It's unfortunately not as good a fit for the backend, at least not until an implementation with good support for concurrency appears. It's nice as an extension language in a larger app (through ECL), and as far as dynamic languages go, it's quite performant, so some computation-heavy apps can benefit from using CL (with SBCL). On the other hand, the ecosystem is quite small, which means dependency-heavy apps are better written in something like Python or a mixture of CL and another language (there are two-way bindings to many dynamic languages and there's mature FFI support for compiled languages).
To be perfectly honest: as much as I love Lisp, I personally gave up on trying to use it, for now. For hobby stuff, I found an even more niche solution that is more enjoyable to work with in the GUI/TUI/CLI space. It also doesn't support OS-level threads, but instead provides coroutines for concurrency - I find this side of the trade-off to be useful/beneficial more often, at least in the code I tend to write. I don't believe the time spent learning CL and other Lisps was wasted, but it's become harder and harder to justify going for CL over the past 15 years, and I finally reached a point where I stopped trying. YMMV though, and I would still give CL a chance if it's your first language of this kind (i.e., providing image-based interactive development, a dynamic language with a native compiler with inline assembly support, a multimethod-based object system, and homoiconicity/macros, etc.).
Re: Steel Bank Common Lisp version 2.6.7
#59I wonder sometimes how the world would look like if lisp won and the unit of deployment was a lisp machine image, if that makes sense. How would a kubernetes optimized for lisp look like? How would AWS EC2 look like? etc.
Lisp's been around for 70 years at this point and hordes of developers tried it and said: lovely, but I ain't using it at work. I'm strongly convinced, having used Scheme, CL, Racket, Clojure that Lisp is doomed to be (mostly) a hobby language. The very power of Lisp, macros, dynamic programming, reflection lead to a mess of an ecosystem where every single developer reinvents the wheel and nobody can understand yet a…
Lisp dialects turned out to be extremely practical - I just can't even imagine doing the things I do today with Emacs in anything else. Achieving similar effects with any other tool would be enormously more time consuming and far more frustrating. Sure, it really took me years to get to that point, but even though I had already knew all sorts of other tools which I could've picked to achieve similar results - from bash/zsh, awk, sed and tcl to python, golang and a bunch of others, the way Lisp-driven Emacs lets me get there is beyond meaningful comparison. Nothing even comes close and I'm enormously proficient in vim, I spent almost a decade in IntelliJ and used tons of different IDEs before - from Delphi and Eclipse to Visual Studio and VSCode.
Clojure, at which I scoffed at some point, turned out to be an immensely pragmatic tool for dealing with data. Any kind of data - big or small. It effectively replaced jq in my toolbelt, all my API interrogations happen in a Clojure REPL today. Fetching data from psql, mysql, sqlite and sorting, slicing, dicing, transforming that data interactively, directly from my editor is an absolute delight.
Building simple web-scraping scripts with nbb driving Playwright is so much faster than using any other stack, even javascript is no longer "an obvious choice" for me, even though I spent decades learning its quirks.
Babashka has replaced any kind of bash-scripting - anything longer than three lines almost has no reason to be made in bash/zsh/fish anymore.
Anything Lua-driven is now done with Fennel. It's not even funny how a dozen-lines boilerplate of Lua can be compacted into a simple, reasonable three-liner Fennel macro. Or the way how I can connect to the Hammerspoon REPL and poke through visual elements of any app on Mac, interactively and with ease - is complete and total bananas.
Era of LLMs incidentally highlighted another enormous advantage of Lisp - when you give an LLM a true Lisp REPL, agents stop guessing and start empirically analyzing current state of things and produces working solution faster, costing far less tokens. And you get to watch it solve things interactively, e.g. I often let AI poke through our UI (via Playwright-driven Clojurescript REPL), while monitoring situation in k8s - through nrepl port, connected to Clojure REPL. It literally interactively walks the DOM, finds the selectors, clicks buttons, etc. All without restarts, complex state management and all.
"Well", you may say: "these examples exactly what I'd consider a 'hobby language' territory".
Alas, I have worked in teams where Clojure was used for shipping commercial software and I have seen truly complex projects - Cisco's infosec infrastructure and FindingCircle's complex Kafka topologies. I have met and talked to people working at Netflix, Apple, Amazon, Nubank, CircleCI, etc., and I can confidently say: your self-conviction is absolutely backwards.
Lisp-world has never been more cornucopian than today; we see the proliferation of different tools and new Lisp dialects popping almost every passing week - Jank, Jolt, ClojureDart, Squint, Coalton, Clojerl, LFE, uLisp, etc. It is frankly inconceivable to find today any platform where you can't really run a Lisp. My advice to any programmer who's aspired to become a hacker - do learn Lisp. It comes in handy. For real.
Re: Steel Bank Common Lisp version 2.6.7
#60Earlier quoted context omitted.
We wouldn't have need such barbaric things in a lisp world. :p Personally I think/hope they would have earlier discoveries / more broad usage of the deterministic systems like nix etc, which are built upon functional principles of immutability etc. Maybe the world would be guix/Hurd!
Common Lisp is pretty much the opposite of what people think of as functional nowadays. You're constantly changing the image and everything is mutable.
i would argue that lispers use of mutability was much more surgical and principled but maybe i'm biased