It’s interesting that the baseline has shifted so much. Most of the arguments that it’s refuting are reasons that you should use C/C++ (or Fortran / Pascal / Algol, when the arguments were originally written) instead of Lisp. These days, the baseline would likely be something like Go, Python, Ruby, or JavaScript (maybe C#) for any domain where Lisp is appropriate. All of these are also GC’d languages and so arguments against Lisp that come from the memory management model don’t apply anymore.
At the same time, ecosystem effects have become more important. There are a lot of Common Lisp packages, but if you want a client for some cloud service then it’s far more likely to exist for JavaScript / TypeScript or Python than for Common Lisp. Editor and debugger support for v8 is probably at least as good as it is for SBCL.
One argument continues to apply against Lisp and that’s the availability of qualified developers. It’s hard to hire good C++ developers. It’s harder to hire good Rust developers. It’s much harder to hire experienced Common Lisp developers. It’s easy to hire JavaScript developers and moderately easy to find the good ones. This means that you probably have a higher training burden: a good developer can learn a new language but it will take at least six months for them to be as productive as your existing team. For a startup, that may be very high risk.
Lisp was a conscious decision because it allows a small team to be incredibly productive, plus the fact that it’s a live image allows you to connect to it over the internet and poke and prod the current state, which has really allowed a much clearer understanding of the data.
I wish I could read something like this from 2023.
It seems @vindarel is using Common Lisp to implement commercial products, but I don’t know for sure.
It’s interesting that the baseline has shifted so much. Most of the arguments that it’s refuting are reasons that you should use C/C++ (or Fortran / Pascal / Algol, when the arguments were originally written) instead of Lisp. These days, the baseline would likely be something like Go, Python, Ruby, or JavaScript (maybe C#) for any domain where Lisp is appropriate. All of these are also GC’d languages and so arguments against Lisp that come from the memory management model don’t apply anymore.
At the same time, ecosystem effects have become more important. There are a lot of Common Lisp packages, but if you want a client for some cloud service then it’s far more likely to exist for JavaScript / TypeScript or Python than for Common Lisp. Editor and debugger support for v8 is probably at least as good as it is for SBCL.
One argument continues to apply against Lisp and that’s the availability of qualified developers. It’s hard to hire good C++ developers. It’s harder to hire good Rust developers. It’s much harder to hire experienced Common Lisp developers. It’s easy to hire JavaScript developers and moderately easy to find the good ones. This means that you probably have a higher training burden: a good developer can learn a new language but it will take at least six months for them to be as productive as your existing team. For a startup, that may be very high risk.
My company is using Common Lisp commercially, also on an embedded system.
There’s this interview https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ from last year, testimonies here and there, like
Feetr (stock market things) https://github.com/azzamsa/awesome-lisp-companies/issues/83 (so, don’t miss this list of companies, a list that was missing a couple years ago)
and yes I implemented and sell commercial products: a web app (a second one in testing), and I also use CL for glue scripts in production© (read a DB, format and send data to FTP servers…). Am I doing exta-ordinary mind-bogging things with CL? With these products no, and that’s the point! You don’t need to find a use case, as I often read. I use CL because I’m super productive with it and it’s fast, stable and easy to deploy (once you know the titbits, but all the issues I encountered are now google-able). It was my deliberate choice to NOT do these products in Python.
(edit): another must-read and must-link-to-everybody post: https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-faster/ why pgloader switched from Python to Common Lisp
Thanks for the links! It’s good to read them. Nice to know that you are implementing commercial products in Common Lisp, awesome!