Fun 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):
I 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.
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.
Sure the language might not be immutable but the lisp machine alt universe's "overton window" would I imagine be more functional then today's (JVM? maybe that's the qnalog?) reality.
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.
yeah it's a strange aspect of that lisp era, it was born in mccarthy's recursive functions over recursive lists.. and then interactive development over global state added as a layer.
i would argue that lispers use of mutability was much more surgical and principled but maybe i'm biased
I would presume there was a lot of mixing of imperative/functional in the 80s where this alt universe starts. I think the same type of world in which lisp machines would have become king would also be similar
> 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.
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:
I'd dearly love to see a RAD (Rapid Application Development) tool using LISP w/ a nifty UI for working up a GUI which would compile to something easily deployed (maybe HTML5 Canvas and JavaScript) as a stand-alone/single-file web application?
sbcl can compile to a single executable (the image is embedded in the binary). From a deployment standpoint, the only real issue is if you depend on a dynamically linked C library like OpenSSL.
Docker deploys is a bit like that I think. Overall, I think many languages and programming systems pick up pieces from each other nowadays. PHP almost by accident can be quite stateless. Yet it's looking more like Java. Many things which could be deployed as an executable, are deployed as VM images. I'm sure we can come up with more things...
We have a few services built in Clojure and we expose nrepl port on our pods in our SDEs, it's enormously helpful to test and debug things on the fly, without having to re-deploy anything.
I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across the wire to execute in another environment. What would modern infrastructure look like if you could just have lambdas running lambdas?
Quite a while back I have read about a system based on Scheme , called termite (I don't remember which scheme that was) that can actually sling live running code/closures across network and execute them remotely..
in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-expression reader you'd have to build a json like subset from first principles. even things like colons in symbol name package:symbol will trip you up. it's been understood since long time ago, that common internet standards, like RFCs, are the preferred method. in which case the fact that it's an s-expression versus a json is pretty much irrelevant. it's a kind of reader/writer anyway.
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 another DSL invented by the next developer next to them.
Racket's theme of being a "programming language for building programming languages" is just the poster child of this naivety: I don't want even more friction.
What scales and works is simple and boring.
That's by the way why also Haskell has struggled forever. Beyond its dreadful DX, poor tooling and unacceptable compilation times, the language is just plagued by compiler extensions and every single developer reinventing its own abstractions.
There was the simple haskell movement to just standardize around a set of extensions and conventions, but nope, these languages unavoidably attract people that want to stay in the ivory tower.
Really, I love both lisps and haskell, but I would take a dreadful php over them every single day at work. No contest.
The problem is that the type of developer you're talking about is the kind who invents a thousand excuses about anything. It doesn't begin and end with different languages. Using a different subset of their favorite language? A different toolchain? A radically different build process? You'll hear plenty of whining about it. Even just moving them to a different codebase will make them miserable. You put a Lisp or a Prolog in front of them, and their attention flows upwards to the most general principles to whine about. The entire thing is that if you stick them into an unfamiliar environment, they will vocalize their discomfort through rationalization. I think most people who have led teams will know exactly what I'm talking about.
Not that these people are necessarily bad at their jobs, but they're definitely a personality type you should learn to identify so you can manage them properly.
I disagree with this profoundly. There is no argument that Lisp in general can get you in a terrible mess. So can C, or pretty much any language (I well remember a case of 11-way multiple inheritance in C++ game code). If I were running a Lisp-based project, there would be project standards (like no exported macros without signoff, and a list of standard library dependencies), documentation requirements, and code review.
The fact that Lisp is the “programmable programming language” doesn't mean that every engineer should be inventing weird versions of while loops. What it does mean is that a skilled Lisp programmer can build a domain-specific language that substantially helps in development.
One good example of this is the Crash Bandicoot games, along with the same studio's Jax and Daxter, which were built with dialects of Lisp (yes, they had to compile the code, and take care with storage allocation, just like any other game code). Cisco hired Kent Dybvig, principal author of the Chez Scheme system, and open-sourced that software; I have no clue what they use it for, to be honest, but I assume that they had some reason for doing this. Companies using various Lisp languages have been documented in areas from fintech to quantum computing.
I was fortunate enough to use lisp professionally for nearly 20 years. The only reason that gig ended was the unfortunate demise of the majority owner and founder, and his heirs selling the shop to a competitor that only wanted the customer database imported. Lisp was never the problem, nor particularily messy.
On the contrary, we considered it a major reason we were able to build a quite successful stock broker and bank from scratch with a team of 4-6 people, who doubled as datacenter ops (we ran on-prem), internal tech support for the rest of the firm (~20 people) and 2.line customer support.
We quite naturally converged on a set of internal libraries for various tasks. Understanding and fixing each other’s code was not a big deal.
Coincidentally, our frontend was php. That was messier, and we conciously kept that layer as lean as possible.
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!
> 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 the ecosystem tends to be small and understandable.
So does the community of every other dialect (Common Lisp, at least). Write a function if you don't have to write a macro, and maybe declaim the function to be inlined.
The "Lisp Curse" is a ridiculous and tired myth that can only be invented by people who have looked at the language for 5 seconds and went straight to finding an excuse to not learn it.
I believe the real issue is that Scheme, which was (through university) often the first and last contact of people with Lisp family languages, has greatly exaggerated case of "everyone reinventing the wheel", and that's before you get into educational reasons that led to people seeing very limited view of Scheme
I think you have very little insight to what you're talking about. The modern Lisp landscape is nothing like what it was in the 90s or even 2000s. The amount of practical shit Lispers been quietly building these days is genuinely impressive.
Have you ever seen GitHub language stats? Elisp there in the list a few points behind Lua, Elixir, OCaml and Haskell. The amount of Emacs Lisp on GitHub alone should be at least surprising. There's so much Elisp in the wild - the amount of it probably exceeds Clojure, CL and Racket combined. And let me remind you that it isn't a "general-purpose PL" - it's meant for one and only purpose. Look at the number of package for AI-coding in Emacs¹ - 35 and counting. Mind that emacs has no central curated marketplace with the same discoverability as VSCode marketplace. Packages live across MELPA, GNU/NonGNU ELPA, and countless personal repos, so a hand-counted 35 from a Reddit roundup is almost certainly an undercount of what exists in the wild.
And that's just one of the observable axes of Lisp. It is hard to find a problem space today or a runtime where Lisp has not proliferated. Why? Because Lisp is enormously practical. Just because you convinced yourself it isn't, doesn't change a thing about reality.
I have a complete and utterly opposite experience. I have used and shipped all sorts of solutions in dozens of different languages before getting to know Lisp. My only regret is that I have not tried learning Lisp sooner - it feels like such a walloping waste of my life.
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 a similar effect 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 used all sorts of other tools which I could've used to achieve similar effects - from bash/zsh, awk, sed, 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 for me.
Anything Lua-driven is now done with Fennel.
Era of LLMs incidentally highlighted another enormous advantage of Lisp - when you give an LLM a true Lisp REPL LLM stops guessing and starts 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.
* 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? Or are these intrinsics you have to explicitly ask for?
If memory serves, traditionally, CCL (Clozure Common Lisp [0]) had better support for Windows but SBCL was unbeatable for speed. Is that still the case?
SBCL works fine on Windows. It used to display a warning about fragility at startup, but that was removed in version 2.0.3, 6 years ago, after already being obsolete for quite a while.
CCL isn't very actively maintained and currently doesn't have an ARM64 port, but otherwise continues to work fine. I believe one reason people use it is that it compiles a bit faster than SBCL, at least in part by doing less optimization.
Part of why SBCL took longer is, IIRC, that SBCL went with embedding proper SEH support into generated code (important among other things to get page fault information), whereas CCL used VEH (which is simpler to use but only available from XP onwards)
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.
A binary has a startup time of like 20 milliseconds, the overwhelming majority of that is setting up page tables iirc. While that's a lot for a small cli utility called in a loop, it's really nothing for a desktop application.
I wish more desktop applications could hit even a 100ms startup time. These days it feels like 5 seconds or more is the norm.
On the contrary, CLI, TUI, and desktop GUI apps are basically the only kinds of apps that benefit from CL and can live with its shortcomings. The startup time of a tool written in CL is short: you just need to load the image into RAM, run some hooks (if configured), and you're good to go. If you don't include loads of dependencies, the dumped image is also not too big, so loading it from an SSD is almost instantaneous. The startup is of course nowhere near that of a small C or Zig binary, but for larger tools it will be tolerable. For TUIs and GUIs, you can work on them interactively and see the changes in the source immediately reflected in the interface of a running instance.
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.).
Fun 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
There's another wordplay in the name.
Namely, that "SB" stands for "Sanely Bootstrappable" - something that the CMU Common Lisp was unable to do
I 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.
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 isn't functional in that sense.
Sure the language might not be immutable but the lisp machine alt universe's "overton window" would I imagine be more functional then today's (JVM? maybe that's the qnalog?) reality.
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.
yeah it's a strange aspect of that lisp era, it was born in mccarthy's recursive functions over recursive lists.. and then interactive development over global state added as a layer.
i would argue that lispers use of mutability was much more surgical and principled but maybe i'm biased
Image saving isn't something that's done very often, in practice.
I would presume there was a lot of mixing of imperative/functional in the 80s where this alt universe starts. I think the same type of world in which lisp machines would have become king would also be similar
> 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.
Yeah, that, uh, doesn't sound like Lisp
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 love to see a RAD (Rapid Application Development) tool using LISP w/ a nifty UI for working up a GUI which would compile to something easily deployed (maybe HTML5 Canvas and JavaScript) as a stand-alone/single-file web application?
You probably want Clog: https://github.com/rabbibotton/clog
sbcl can compile to a single executable (the image is embedded in the binary). From a deployment standpoint, the only real issue is if you depend on a dynamically linked C library like OpenSSL.
Docker deploys is a bit like that I think. Overall, I think many languages and programming systems pick up pieces from each other nowadays. PHP almost by accident can be quite stateless. Yet it's looking more like Java. Many things which could be deployed as an executable, are deployed as VM images. I'm sure we can come up with more things...
> How would a kubernetes
We have a few services built in Clojure and we expose nrepl port on our pods in our SDEs, it's enormously helpful to test and debug things on the fly, without having to re-deploy anything.
Not In production yes?
Also not sure what is SDE.
I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across the wire to execute in another environment. What would modern infrastructure look like if you could just have lambdas running lambdas?
Not sexps, but better.
Quite a while back I have read about a system based on Scheme , called termite (I don't remember which scheme that was) that can actually sling live running code/closures across network and execute them remotely..
Boggles my mind even today.
in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-expression reader you'd have to build a json like subset from first principles. even things like colons in symbol name package:symbol will trip you up. it's been understood since long time ago, that common internet standards, like RFCs, are the preferred method. in which case the fact that it's an s-expression versus a json is pretty much irrelevant. it's a kind of reader/writer anyway.
Same as the regular, but configurable in lisp?
Not that different.
AWS already has lots of AMI and docker are essentially image based.
We would version whole images in something like git, and that's all.
Variable AWS is unbound.
It'd look like Graal, which is a real thing you can use today.
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 another DSL invented by the next developer next to them.
Racket's theme of being a "programming language for building programming languages" is just the poster child of this naivety: I don't want even more friction.
What scales and works is simple and boring.
That's by the way why also Haskell has struggled forever. Beyond its dreadful DX, poor tooling and unacceptable compilation times, the language is just plagued by compiler extensions and every single developer reinventing its own abstractions.
There was the simple haskell movement to just standardize around a set of extensions and conventions, but nope, these languages unavoidably attract people that want to stay in the ivory tower.
Really, I love both lisps and haskell, but I would take a dreadful php over them every single day at work. No contest.
The problem is that the type of developer you're talking about is the kind who invents a thousand excuses about anything. It doesn't begin and end with different languages. Using a different subset of their favorite language? A different toolchain? A radically different build process? You'll hear plenty of whining about it. Even just moving them to a different codebase will make them miserable. You put a Lisp or a Prolog in front of them, and their attention flows upwards to the most general principles to whine about. The entire thing is that if you stick them into an unfamiliar environment, they will vocalize their discomfort through rationalization. I think most people who have led teams will know exactly what I'm talking about.
Not that these people are necessarily bad at their jobs, but they're definitely a personality type you should learn to identify so you can manage them properly.
Yes, that kind of developer exists everywhere, but is still limited by the tools you reign in him.
> I think most people who have led teams will know exactly what I'm talking about.
I've had those as leads themselves, with great benefit and pain. They further convinced me about the beauty of ugly and boring.
I disagree with this profoundly. There is no argument that Lisp in general can get you in a terrible mess. So can C, or pretty much any language (I well remember a case of 11-way multiple inheritance in C++ game code). If I were running a Lisp-based project, there would be project standards (like no exported macros without signoff, and a list of standard library dependencies), documentation requirements, and code review.
The fact that Lisp is the “programmable programming language” doesn't mean that every engineer should be inventing weird versions of while loops. What it does mean is that a skilled Lisp programmer can build a domain-specific language that substantially helps in development.
One good example of this is the Crash Bandicoot games, along with the same studio's Jax and Daxter, which were built with dialects of Lisp (yes, they had to compile the code, and take care with storage allocation, just like any other game code). Cisco hired Kent Dybvig, principal author of the Chez Scheme system, and open-sourced that software; I have no clue what they use it for, to be honest, but I assume that they had some reason for doing this. Companies using various Lisp languages have been documented in areas from fintech to quantum computing.
I was fortunate enough to use lisp professionally for nearly 20 years. The only reason that gig ended was the unfortunate demise of the majority owner and founder, and his heirs selling the shop to a competitor that only wanted the customer database imported. Lisp was never the problem, nor particularily messy.
On the contrary, we considered it a major reason we were able to build a quite successful stock broker and bank from scratch with a team of 4-6 people, who doubled as datacenter ops (we ran on-prem), internal tech support for the rest of the firm (~20 people) and 2.line customer support.
We quite naturally converged on a set of internal libraries for various tasks. Understanding and fixing each other’s code was not a big deal.
Coincidentally, our frontend was php. That was messier, and we conciously kept that layer as lean as possible.
I use Common Lisp at work.
Me too
>> said: lovely, but I ain't using it at work.
Says who, you? Wrong. I use Common Lisp at work.
edit: and not just use as in a side toy, design and writing software in CL is my primary responsibility. FWIW, at a FAANG!
>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!
Sounds like a dream job, tbh
> 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 the ecosystem tends to be small and understandable.
It seems to me the Clojure community internalized the lesson of not writing macros unless it's really necessary more than other Lisps did.
So does the community of every other dialect (Common Lisp, at least). Write a function if you don't have to write a macro, and maybe declaim the function to be inlined.
The "Lisp Curse" is a ridiculous and tired myth that can only be invented by people who have looked at the language for 5 seconds and went straight to finding an excuse to not learn it.
I believe the real issue is that Scheme, which was (through university) often the first and last contact of people with Lisp family languages, has greatly exaggerated case of "everyone reinventing the wheel", and that's before you get into educational reasons that led to people seeing very limited view of Scheme
Further confirming my point on why it is the only lisp with some genuine traction out there.
I think you have very little insight to what you're talking about. The modern Lisp landscape is nothing like what it was in the 90s or even 2000s. The amount of practical shit Lispers been quietly building these days is genuinely impressive.
Have you ever seen GitHub language stats? Elisp there in the list a few points behind Lua, Elixir, OCaml and Haskell. The amount of Emacs Lisp on GitHub alone should be at least surprising. There's so much Elisp in the wild - the amount of it probably exceeds Clojure, CL and Racket combined. And let me remind you that it isn't a "general-purpose PL" - it's meant for one and only purpose. Look at the number of package for AI-coding in Emacs¹ - 35 and counting. Mind that emacs has no central curated marketplace with the same discoverability as VSCode marketplace. Packages live across MELPA, GNU/NonGNU ELPA, and countless personal repos, so a hand-counted 35 from a Reddit roundup is almost certainly an undercount of what exists in the wild.
And that's just one of the observable axes of Lisp. It is hard to find a problem space today or a runtime where Lisp has not proliferated. Why? Because Lisp is enormously practical. Just because you convinced yourself it isn't, doesn't change a thing about reality.
---
¹ https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...
I have a complete and utterly opposite experience. I have used and shipped all sorts of solutions in dozens of different languages before getting to know Lisp. My only regret is that I have not tried learning Lisp sooner - it feels like such a walloping waste of my life.
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 a similar effect 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 used all sorts of other tools which I could've used to achieve similar effects - from bash/zsh, awk, sed, 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 for me.
Anything Lua-driven is now done with Fennel.
Era of LLMs incidentally highlighted another enormous advantage of Lisp - when you give an LLM a true Lisp REPL LLM stops guessing and starts 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.
No auto-vectorization yet, but you may find this illuminating: https://www.stylewarning.com/posts/nbody
And the very recent https://old.reddit.com/r/lisp/comments/1v6kyyn/so_they_say_l...
Looks like you use it explicitly?
https://github.com/sbcl/sbcl/tree/master/contrib/sb-simd
If any SBCL dev is here, please add documentation for how to use the memory arena feature. The only doc is an very old proposal document.
Yeah I'm not sure why it's not in the manual, as it's had arena allocation support since at least 2.4.x, but basically:
- use SB-VM:NEW-ARENA to make a new arena
- use SB-VM:WITH-ARENA to redirect ordinary allocation into an existing arena like you would use WITH-OPEN-FILE or similar macros
The only real doc is this internals note, and it doesn't even cover NEW-ARENA which I guess is left as an exercise to the reader: https://github.com/sbcl/sbcl/blob/master/doc/internals-notes...
If 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/
SBCL works fine on Windows. It used to display a warning about fragility at startup, but that was removed in version 2.0.3, 6 years ago, after already being obsolete for quite a while.
CCL isn't very actively maintained and currently doesn't have an ARM64 port, but otherwise continues to work fine. I believe one reason people use it is that it compiles a bit faster than SBCL, at least in part by doing less optimization.
Part of why SBCL took longer is, IIRC, that SBCL went with embedding proper SEH support into generated code (important among other things to get page fault information), whereas CCL used VEH (which is simpler to use but only available from XP onwards)
Great to see the project is still going strong, I kinda want to try CL but I always feel like I don't have a great use-case.
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.
A binary has a startup time of like 20 milliseconds, the overwhelming majority of that is setting up page tables iirc. While that's a lot for a small cli utility called in a loop, it's really nothing for a desktop application.
I wish more desktop applications could hit even a 100ms startup time. These days it feels like 5 seconds or more is the norm.
On the contrary, CLI, TUI, and desktop GUI apps are basically the only kinds of apps that benefit from CL and can live with its shortcomings. The startup time of a tool written in CL is short: you just need to load the image into RAM, run some hooks (if configured), and you're good to go. If you don't include loads of dependencies, the dumped image is also not too big, so loading it from an SSD is almost instantaneous. The startup is of course nowhere near that of a small C or Zig binary, but for larger tools it will be tolerable. For TUIs and GUIs, you can work on them interactively and see the changes in the source immediately reflected in the interface of a running instance.
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.).
I have a todo list longer than the Tour de France I want to tackle first!
I'm going pretty deep on Lisp on accident - can anybody give me more context on this?
You might find this interesting: https://news.ycombinator.com/item?id=43636230
more context beyond the changelog? what would you like to know?
(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
#|))))
Great semver number