Rendered at 04:47:08 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
varoun 4 hours ago [-]
I spent the last year writing substantial Common Lisp, including a FoundationDB client and distributed systems primitives layered on top of that, an observability and operability library for CL systems, and a large scale log, metrics and tracing platform that leverages these - in about 200K lines of code and tests.
My take on this, apart from one of familiarity and personal preference/taste in choosing a programming language, in the age of LLMs are -
1. From a “functional requirements” perspective, any language will do. You can build substantial systems in something low level like C or higher level like Python or Common Lisp for example.
2. From a security perspective, if you are using LLM assisted code generation, whether you use C or Rust or Common Lisp does not really matter I think - current models are capable, and future models perhaps more so, in producing secure code.
My understanding is that LLM are deflationary, resulting in code being priced as a commodity (cost plus). If this bears out, then lower token costs and higher performance (esp in my case, where good performance results in lower infra costs to host the service) will start to matter more and more. Common Lisp code bases are famously dense (in the good sense), resulting in perhaps lower token costs when an LLM needs to review and make a change (smaller code bases also help humans / small teams). Common Lisp can achieve performance that’s close to that of an equivalent implementation in C or C++.
Taken together, they make for one case for using CL and other similar languages, although one that’s grounded largely in economics.
davemp 32 minutes ago [-]
I couldn’t help but notice the parent commenter’s post history. Account from literally before this was called HN, one comment 6 years later, then 13 years later this comment.
The pro lisp/s expression comments check out.
massysett 4 hours ago [-]
But will an LLM write dense Common Lisp? A lot of that density comes from well-designed domain-specific macros. An LLM will have no incentive to write these on its own, though it could if a human prods it sufficiently.
abbefaria27 58 minutes ago [-]
I spent quite a while trying to learn Common Lisp and I really wanted to like it, but I’m not sure I’d recommend it. The first problem is finding good learning materials, as most are out of print. On the language side people complain about the parens, which turns out is no big deal. There’s a lot of other weird or needlessly tricky stuff though. The function names are convoluted (e.g. there’s map, but also mapc, mapcan, mapl, maplist). Image based development was interesting, but you might waste an hour debugging because your image diverged from the actual code. Building an actual executable is more complicated than you’d expect, and there’s a lot of magic with packages. There’s some elegance there if you squint, but other lisps are probably better.
I now generate ALL of my hobby projects in CL (SBCL on windows). I tell the LLM to 'over-comment' the code, so I get to learn as I read the output. It has been glorious. I generally use the web browser on an unused port on localhost for user IO (beautiful pages), and the app just hooks to Hunchentoot to serve.
Any 'real' programming language (meaning, one that is truly general purpose: numeric stacks, Web front and back ends, system code, utilities, etc) will always have some cruft. In CL, at least you can understand why some cruft exists. And you get used to it, because it's not like e.g. C where there are some very dark corners indeed. Check out Peter's book!
CL lets you build real apps, for real. No toys. This has value.
shric 5 hours ago [-]
I’m fascinated that some people in our field choose to self describe themselves as “elite”.
Are there any programming/computer science greats that self aggrandize like this? Is it a cultural thing somewhere that I’m not aware of?
aag 35 minutes ago [-]
I've known Joe for decades. I've never heard him describe himself this way, but I can confirm that it is true. He is amazing.
deterministic 11 minutes ago [-]
I know a lot of amazing developers, but they never claim to be “elite” or make similar nonsense claims. They let their work speak for itself.
jpcom 5 hours ago [-]
Roughly just over one-thousand people, precisely 1,337 people self-describe as elite in the field.
pfdietz 3 hours ago [-]
And 420 people can describe themselves as baked.
monocasa 3 hours ago [-]
We got two extras once we figured out that 422 is 420 too.
aidenn0 5 hours ago [-]
I've been programming in Common Lisp for a quarter century and that list item made me cringe.
kazinator 4 hours ago [-]
I'm into Lisp because Lisp languages are easy to work in. I advocate the family as being good for nonprogrammers.
Small children should learn some kind of Lisp, and easily can.
Richard Stallman famously shared an anecdote in the article "My Lisp Experiences and the Development of GNU Emacs" (https://www.gnu.org/gnu/rms-lisp.en.html) about the secretaries:
> The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
People, whether inside or outside of Lisp, who spread myths that that it is some scary, esoteric elite family of languages, have been pretty harmful.
deterministic 19 minutes ago [-]
Game designers in the games industry use Lua (and other script languages) all the time without being programmers. That doesn't mean that those languages are more "elite" than others.
Also, I taught myself machine code programming when I was 11. Just using a book (no help, no internet). So don't underestimate what kids can learn.
kodoman 4 hours ago [-]
Most well known Dijkstra, who it can safely be said, is one of the greats. Though this blog post is a little much with the whole elite thing there is a little much, I think a rather terrible attitude that is antithetical to it is that of 'Democratization' which seeks to strip skill and need to learn from building and interacting with technology often at the expense of many positive attributes. It hates any thing that requires skill or simply prior learning to use well despite often these things meaning the system overall can better serve the user better and one the prior work has been done is more effective.
Further this 'Democritisation' can be seen as trying to deskill something that taking away many positives and having contempt for skill. I believe This is often simply to devalue software developers and I assume you are one so I believe we should both be cautious of this devaluation.
I think a more interesting question would be why should we not have elite's and I don't know if I am unusual but false humility always rubs me the wrong way?
chris_armstrong 2 hours ago [-]
I interpreted this as being a little tongue-in-cheek - reflecting the obscurity of CL and the way the expressiveness of a lisp can make you feel powerful that others will struggle to understand
kazinator 4 hours ago [-]
"Für Elite" by Letrec Var Bughaven
BigTTYGothGF 5 hours ago [-]
Describing oneself as "elite" (or sometimes "l33t") is something people in this field have been doing for a long long time.
aidenn0 5 hours ago [-]
And people who do so have been a punchline for a long time:
Lisp is a highly expressive language with little constraint, so there’s plenty of room for individuals to become strongly opinionated. That leads to a bit of elite mindset.
stackghost 2 hours ago [-]
I don't get the impression the author is attributing eliteness to themselves. Wanting to use tools designed by and for "the elite", whomever that is, doesn't mean one necessarily considers themselves to be elite.
When it comes to writing software, I don't consider myself elite, but neither do I want to use a language designed by some mid-level engineer. Do you?
deterministic 22 minutes ago [-]
It seems to happen a lot with Lisp enthusiasts for some reason, usually without any evidence to back it up.
It always makes me laugh because the real world runs on C/C++, not Lisp. So perhaps by “elite” they mean something other than being successful in the real world? Maybe they think they “get it” while everyone else doesn’t, which somehow makes them “elite”? A bit like conspiracy theorists who think they’re among the few smart enough to know the “truth.” Not sure.
Once you've toiled on the learning curve of Lisp long enough to really grok it you might begin to think you've discovered the foundational bedrock of the universe. From that perspective it's kind of hard not to be a little condescending toward fans of other languages.
It doesn't help that younger programmers today who complain about "too many parentheses" are largely unaware that Lisp was the original language of AI because the guy who invented AI also invented Lisp to help him do AI. I for one am just a tiny bit chuffed about that because I'm certain that more and better progress on LLMs (and beyond) would have happened had Lisp been used instead of Python as the primary vehicle for AI exploration.
So yeah, I damn well consider myself elite and I won't apologize for it.
bogdanoff_2 2 hours ago [-]
> Once you've toiled on the learning curve of Lisp long enough to really grok it you might begin to think you've discovered the foundational bedrock of the universe.
Could it be a form of self-selection bias? That the kind of person that is likely to have such thoughts about a (family of) programming language is also more likely to start and preservere with Lisp?
> I for one am just a tiny bit chuffed about that because I'm certain that more and better progress on LLMs (and beyond) would have happened had Lisp been used instead of Python as the primary vehicle for AI exploration.
Yeah… clearly “not using lisp enough” was the major bottleneck in AI development over the last 40 years. /s
(While we’re patting ourselves on the backs for no reason, I’m certain that modern AI is as big of an argument for worse is better as C and Unix ever were.)
deterministic 8 minutes ago [-]
> Lisp was the original language of AI
Ahhh so that's why the AI winter happened? Wrong programming language? /s
drekipus 5 hours ago [-]
Too noob to get it
huffhuffhuff 1 hours ago [-]
Elite programmers are people that have excelled at their field for decades. I know I excelled because I have patents, publications, successful products used by millions (if not billions) and a bank account to prove it. Elite coders reading this will just nod, but noobs will make a noise like “huff huff huff” while frantically typing angry responses.
leoooodias 1 hours ago [-]
I made a billion successful apps. Each used by trillions.
tigermelville 24 minutes ago [-]
Wrote my first Lisp program in high school 1974; during a teacher's strike some of us geeks bussed it down to the University of Toronto computing centre. It was cafeteria system with a room full of keypunch machines. You typed up your program and got in line with your card deck. The line started with some silos of job cards. You could write fortran, lisp, pl/1, watbol, snobol, etc and run it on an IBM 360 mainframe.
You placed your deck on top of the card hopper when your turn came up. Most programs were 1/2 inch of cards so there were lots of jobs in a hopper that would take two feet of cards.
The line continued until a 1442 line printer at the end where your resulting printout came reeling out at alarming speeds. Operators handed you your printout and you returned to the keypunch room to review your results and make the necessary changes to your card deck.
The cool thing was we were obviously 15 years old and definitely not attending U of T. And our jobs were plainly not for a class because our card decks were 1 1/2 inches thick with long printouts of gameboard configurations.
But nobody ever batted an eye. We went every day for months.
Eventually I went to Uni during the era of the lisp machines. I worked for a professor who got me an office in the cpsc building. He paid me slave wages but the Lisp Machine lab was across from my office so they gave me a key to let people in who didn't have theirs. Bunch of Symbolics 36xx machines running chaosnet. A loud but life altering experience spending time in there. I spent enough time that I had a cot in my office.
That was mid 1980s, and I've carried on writing Lisp to this day. I still like to run that emulated Symbolics environment that's out there. To this day it's a very effective Lisp environment. The design of the REPL alone is blow-your-mind.
Am I elite? No, but my beard is grey. And on the subject of code generation, the last thing Symbolics did was port their code to the DEC Alpha, the first 64 bit chip. The port compiled their code into lisp macros that expanded to DEC Alpha instructions. The plan was to use different macros for different chips, which was done when the Power PC chip came along.
Then somebody at MIT wrote a little C backend that pretended to be a DEC alpha,
and used macros that expanded into calls to the little C backend. That's what allows us to run a mid 1990s Symbolics 3600 image on any of today's 64 bit machines.
tehologist 2 hours ago [-]
I was under the impression LISP is nice to write and work with but difficult to read. How well can you understand LISP written by a LLM?
dismalaf 11 minutes ago [-]
Honestly LLMs write decent enough Lisp. They do however tend to want to use only functions and thus it ends up a bit verbose, but prod them enough and they'll make macros that work and write nice code. Lisp written by LLM is nicer than Ruby or C++ written by an LLM.
rodrigosetti 3 hours ago [-]
Google is making the opposite argument to support Go as the ideal language for vibe coding (https://news.ycombinator.com/item?id=49261133) - i.e., not expressive by design, lowest-denominator, etc.
stackghost 3 hours ago [-]
The thing I like about using Go for vibe coding is that, as Google and others argue, there's almost always one obvious way to do things, and the standard library is enormous so there's almost always an easy choice of library to do things with. As a result of that, almost all the Go in the training set for these models is going to be decent.
Compare that to, shall we say, more permissive (and more popular!) languages like python or js where there are untold terabytes of absolute dogshit code out there.
But I find Go annoying because the language isn't very expressive. It takes a lot of code to do fairly simple things, so codebases tend to balloon in size very quickly.
If only the library ecosystem in common lisp wasn't so barren.
kodoman 4 hours ago [-]
I have been using cl for a project recently, as it had many features I wanted and actually made sense to use despite not being familiar with it (though used elisp and a tiny bit of scheme). I found it mixed some things where fantastic some things remain pain points, SBCL is a fantastic project and compiler and once you get used to the debugging it's a very nice experience with slime. It is true to say that it's flexibility is fantastic and CLOS object system once you get used to it is very nice. On AI assisted coding I found it mixed and though Claude now seems quite good at it, local models can be quite poor and lots of things are a lot less well documented and the fact that there is less code out there. One thing to look out for with local models (and probably even the frontier models but with there larger size negates the issue entirely from my usage) is that '(' or ')' might be part of a token such that '))' is a discrete token and '(*' might be as well, all that is to say that when it writes code terminating and start blocks can be an issue so your parens will be off, this was when using omnicoder 9B and that was the main issue. not sure how more recent local models function as switched to claude for part of it and tended to prefer to take my time and write the code myself.
mark_l_watson 1 hours ago [-]
In the mid 1980s I wrote a commercial neural network product SAIC Ansim and I usually got things working in Common Lisp first, then manually translated to C++. Now we can write in CL and use coding agents to translate to other languages... progress!!
PrimalPower 5 hours ago [-]
I don't know if anything has changed, but last time I tried codegen for Common Lisp, the LLM would routinely mix up LISP dialects and language specific features.
Less so with Clojure.
wild_egg 5 hours ago [-]
I've been using LLMs for Common Lisp since Sonnet 3.7 and have never experienced that. Did you have a mixture of other lisps nearby to confuse it? Seems like an odd failure mode.
rhet0rica 4 hours ago [-]
This is an inevitable result of small dataset size. As recently as the start of this year, flagship models struggled with Objective-C unless the target was Apple's latest API. (This is per GNUstep lead dev Gregory Casamento, who has every reason to be an expert in these things.)
tehologist 2 hours ago [-]
As an aside, I wrote a dialect of forth and LLM was pretty good about constraining itself to a subset and create fairly usable code. I was having it implement cordic functions to implement sin/cos.
xdavidliu 2 hours ago [-]
> You are not writing dead text; you are conversing with a living system.
There it is again.
zapataband1 2 hours ago [-]
"conversing with a living system" aka "using a common debugging tool"
throw10920 1 hours ago [-]
I don't understand. Are you saying that you think that writing Common Lisp is akin to using a debugger in other programming languages?
maleldil 48 minutes ago [-]
REPLs aren't debuggers.
sillysaurusx 4 hours ago [-]
One annoying part of SBCL is that it does something up front with its memory such that if you run it with an 8GB heap, running shell commands takes a noticeably long time even for "echo hi". It’s something to do with the way it forks. Shell commands are also serialized, meaning multiple threads running curl won’t help you more than a single thread running curl. This is in contrast to almost every other programming language, which lets you get more performant network fetches by running the requests in multiple threads. The only alternative to curl is to use a library that simulates curl or write your own, which is fraught with errors: if any piece of the connection times out, it has to gracefully terminate, which is harder than it sounds when you’re interfacing with OpenSSL directly.
I think that covers my list of grievances though, and it’s a pretty short list. Other than those, CL has been good to me.
dismalaf 4 hours ago [-]
Was going to write something about the article but then poked around the blog and it led to Github including this gem: https://github.com/jrm-code-project/llambda which is much more interesting.
I do agree with a lot of the article though, Lisp plays nicely with LLMs. Definitely had better luck with Lisp and LLMs than C++ or Rust.
>I do not operate the LLM in a sterile text editor. I operate it from within a Lisp REPL
I'd be very interested in reading more about this.
samso26 5 hours ago [-]
[flagged]
ohaodha 4 hours ago [-]
[dead]
a2ff6eeb0 5 hours ago [-]
In short: sunk cost fallacy.
ggm 2 hours ago [-]
An answer appealing for both it's brevity, and the potential recursive application. Use wisely lest stack overflow in discussion threads eventuates.
rhet0rica 4 hours ago [-]
Counterargument—weaknesses of Lisp:
1. The author's first argument is that CL is familiar to them—fine. However, this does not translate into any benefits for the model and is not generalizable.
2. The second argument is that HLLs are an unqualified good, and again that they reflect the desires of the author. It's certainly true that having less boilerplate to manage reduces the surface area for mistakes, and makes code easier to review, but this is only a very weak argument in Lisp's favor. Given the right library, most HLLs can be as flexible as Lisp, especially newer ones where questions about standard library design and collection behavior are still being explored. Conversely CL's standard library is indebted to decades of history. No racehorse wins races forever.
3. The third argument is that Lisp was somehow intended for exclusive use by qualified individuals—this is absolute brainrot. It was designed to manage recursive structures on an IBM 704, and that's about it. It then repeats an unrelated statement about CL being 'built for maximum expressiveness', calling back to the second point; it has been surpassed.
4. The fourth argument trots out the infamous dead horse of homoiconicity. Parentheses have low information density. The LLM wastes a huge amount of context on indentation already, and to have only one style of parenthesis for the vast majority of code is contrary to its expertise. If you want to claim homoiconicity as an advantage, then you need to make your model generate an actual tree data structure, not indented, linear, parenthetical strings. LLMs cannot do this; the harness required defeats the benefit. Therefore point 4 is totally wrong. Homoiconic languages are only of value when you need something that resembles the intermediate state of a compiler—i.e., for macro transformations. The Markov-model-like architecture of an LLM does not benefit from this property whatsoever.
5. Next the author brings up using macros to form a DSL. If the macro is shallow (i.e. it doesn't perform deep syntax transformation) then it is just syntactic sugar and could be a function. If the macro is deep (i.e. it restructures all kinds of stuff) then you are putting a cognitive burden on the LLM to keep track of which syntactic rules apply, and the risk of failure goes up.
6. The author mentions that REPLs exist. This is, again, an example of wearing blinders. REPLs are so common and so good now that even web browsers come with better JS REPLs than a command-line.
7. The author thinks it is amazing when a development environment triggers a breakpoint instead of crashing on a failure. This feature is so standard that even gdb and MSVC do it. Visual Basic, famously, did it quite well.
8. Hot-reloading functions: This is, again, possible in a wide variety of languages, though not always as a default feature. For example, IPython adds this behavior to Python. Hot-reloading is not widespread because it often results in inconsistent program state.
Virtually all of CL's strengths are outmoded or defeated by giving the job of programming to a machine. It's like putting velvet inside your toilet tank: sure, it's fancy, but nobody benefits.
Even more importantly, though, the pool of available training data for CL is vanishingly small compared to other languages, which will increase the error rate dramatically. You should expect a lower quality of code for CL, and a high frequency of it being confused for similar, more popular languages like Scheme and Clojure. LLMs actually excel at Clojure, in part because its syntax is crunchier. All that sugar—applied consistently across the language, not sporadically in a rare DSL macro—helps the LLM keep track of what it's doing and where it is.
mtlmtlmtlmtl 57 minutes ago [-]
I'll never understand why people post LLM outputs in forums pretending they wrote it themselves.
You asked Claude or some other agent to make your argument for you, and what you got was a well formatted pile of nothing. Bravo.
dreamcompiler 4 hours ago [-]
> Conversely CL's standard library is indebted to decades of history.
There's no such thing as "CL's standard library." I presume you mean the functions built into Common Lisp which provide basic functionality, but nobody uses "bare" Common Lisp any more than anybody uses bare C. The Quicklisp libraries for CL (among others) provide the modern utilities you seem to think CL lacks.
My understanding is that LLM are deflationary, resulting in code being priced as a commodity (cost plus). If this bears out, then lower token costs and higher performance (esp in my case, where good performance results in lower infra costs to host the service) will start to matter more and more. Common Lisp code bases are famously dense (in the good sense), resulting in perhaps lower token costs when an LLM needs to review and make a change (smaller code bases also help humans / small teams). Common Lisp can achieve performance that’s close to that of an equivalent implementation in C or C++.
Taken together, they make for one case for using CL and other similar languages, although one that’s grounded largely in economics.
The pro lisp/s expression comments check out.
I now generate ALL of my hobby projects in CL (SBCL on windows). I tell the LLM to 'over-comment' the code, so I get to learn as I read the output. It has been glorious. I generally use the web browser on an unused port on localhost for user IO (beautiful pages), and the app just hooks to Hunchentoot to serve.
Any 'real' programming language (meaning, one that is truly general purpose: numeric stacks, Web front and back ends, system code, utilities, etc) will always have some cruft. In CL, at least you can understand why some cruft exists. And you get used to it, because it's not like e.g. C where there are some very dark corners indeed. Check out Peter's book!
CL lets you build real apps, for real. No toys. This has value.
Are there any programming/computer science greats that self aggrandize like this? Is it a cultural thing somewhere that I’m not aware of?
Small children should learn some kind of Lisp, and easily can.
Richard Stallman famously shared an anecdote in the article "My Lisp Experiences and the Development of GNU Emacs" (https://www.gnu.org/gnu/rms-lisp.en.html) about the secretaries:
> The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
People, whether inside or outside of Lisp, who spread myths that that it is some scary, esoteric elite family of languages, have been pretty harmful.
Also, I taught myself machine code programming when I was 11. Just using a book (no help, no internet). So don't underestimate what kids can learn.
Further this 'Democritisation' can be seen as trying to deskill something that taking away many positives and having contempt for skill. I believe This is often simply to devalue software developers and I assume you are one so I believe we should both be cautious of this devaluation.
I think a more interesting question would be why should we not have elite's and I don't know if I am unusual but false humility always rubs me the wrong way?
https://megatokyo.com/strip/70
When it comes to writing software, I don't consider myself elite, but neither do I want to use a language designed by some mid-level engineer. Do you?
It always makes me laugh because the real world runs on C/C++, not Lisp. So perhaps by “elite” they mean something other than being successful in the real world? Maybe they think they “get it” while everyone else doesn’t, which somehow makes them “elite”? A bit like conspiracy theorists who think they’re among the few smart enough to know the “truth.” Not sure.
Once you've toiled on the learning curve of Lisp long enough to really grok it you might begin to think you've discovered the foundational bedrock of the universe. From that perspective it's kind of hard not to be a little condescending toward fans of other languages.
It doesn't help that younger programmers today who complain about "too many parentheses" are largely unaware that Lisp was the original language of AI because the guy who invented AI also invented Lisp to help him do AI. I for one am just a tiny bit chuffed about that because I'm certain that more and better progress on LLMs (and beyond) would have happened had Lisp been used instead of Python as the primary vehicle for AI exploration.
So yeah, I damn well consider myself elite and I won't apologize for it.
Could it be a form of self-selection bias? That the kind of person that is likely to have such thoughts about a (family of) programming language is also more likely to start and preservere with Lisp?
Yeah… clearly “not using lisp enough” was the major bottleneck in AI development over the last 40 years. /s
(While we’re patting ourselves on the backs for no reason, I’m certain that modern AI is as big of an argument for worse is better as C and Unix ever were.)
Ahhh so that's why the AI winter happened? Wrong programming language? /s
You placed your deck on top of the card hopper when your turn came up. Most programs were 1/2 inch of cards so there were lots of jobs in a hopper that would take two feet of cards.
The line continued until a 1442 line printer at the end where your resulting printout came reeling out at alarming speeds. Operators handed you your printout and you returned to the keypunch room to review your results and make the necessary changes to your card deck.
The cool thing was we were obviously 15 years old and definitely not attending U of T. And our jobs were plainly not for a class because our card decks were 1 1/2 inches thick with long printouts of gameboard configurations.
But nobody ever batted an eye. We went every day for months.
Eventually I went to Uni during the era of the lisp machines. I worked for a professor who got me an office in the cpsc building. He paid me slave wages but the Lisp Machine lab was across from my office so they gave me a key to let people in who didn't have theirs. Bunch of Symbolics 36xx machines running chaosnet. A loud but life altering experience spending time in there. I spent enough time that I had a cot in my office.
That was mid 1980s, and I've carried on writing Lisp to this day. I still like to run that emulated Symbolics environment that's out there. To this day it's a very effective Lisp environment. The design of the REPL alone is blow-your-mind.
Am I elite? No, but my beard is grey. And on the subject of code generation, the last thing Symbolics did was port their code to the DEC Alpha, the first 64 bit chip. The port compiled their code into lisp macros that expanded to DEC Alpha instructions. The plan was to use different macros for different chips, which was done when the Power PC chip came along.
Then somebody at MIT wrote a little C backend that pretended to be a DEC alpha, and used macros that expanded into calls to the little C backend. That's what allows us to run a mid 1990s Symbolics 3600 image on any of today's 64 bit machines.
Compare that to, shall we say, more permissive (and more popular!) languages like python or js where there are untold terabytes of absolute dogshit code out there.
But I find Go annoying because the language isn't very expressive. It takes a lot of code to do fairly simple things, so codebases tend to balloon in size very quickly.
If only the library ecosystem in common lisp wasn't so barren.
Less so with Clojure.
There it is again.
I think that covers my list of grievances though, and it’s a pretty short list. Other than those, CL has been good to me.
I do agree with a lot of the article though, Lisp plays nicely with LLMs. Definitely had better luck with Lisp and LLMs than C++ or Rust.
Also, kind of random, but here's an interesting tool to use CL with LLMs: https://www.lambda-symbolics.com/autolith
I'd be very interested in reading more about this.
1. The author's first argument is that CL is familiar to them—fine. However, this does not translate into any benefits for the model and is not generalizable.
2. The second argument is that HLLs are an unqualified good, and again that they reflect the desires of the author. It's certainly true that having less boilerplate to manage reduces the surface area for mistakes, and makes code easier to review, but this is only a very weak argument in Lisp's favor. Given the right library, most HLLs can be as flexible as Lisp, especially newer ones where questions about standard library design and collection behavior are still being explored. Conversely CL's standard library is indebted to decades of history. No racehorse wins races forever.
3. The third argument is that Lisp was somehow intended for exclusive use by qualified individuals—this is absolute brainrot. It was designed to manage recursive structures on an IBM 704, and that's about it. It then repeats an unrelated statement about CL being 'built for maximum expressiveness', calling back to the second point; it has been surpassed.
4. The fourth argument trots out the infamous dead horse of homoiconicity. Parentheses have low information density. The LLM wastes a huge amount of context on indentation already, and to have only one style of parenthesis for the vast majority of code is contrary to its expertise. If you want to claim homoiconicity as an advantage, then you need to make your model generate an actual tree data structure, not indented, linear, parenthetical strings. LLMs cannot do this; the harness required defeats the benefit. Therefore point 4 is totally wrong. Homoiconic languages are only of value when you need something that resembles the intermediate state of a compiler—i.e., for macro transformations. The Markov-model-like architecture of an LLM does not benefit from this property whatsoever.
5. Next the author brings up using macros to form a DSL. If the macro is shallow (i.e. it doesn't perform deep syntax transformation) then it is just syntactic sugar and could be a function. If the macro is deep (i.e. it restructures all kinds of stuff) then you are putting a cognitive burden on the LLM to keep track of which syntactic rules apply, and the risk of failure goes up.
6. The author mentions that REPLs exist. This is, again, an example of wearing blinders. REPLs are so common and so good now that even web browsers come with better JS REPLs than a command-line.
7. The author thinks it is amazing when a development environment triggers a breakpoint instead of crashing on a failure. This feature is so standard that even gdb and MSVC do it. Visual Basic, famously, did it quite well.
8. Hot-reloading functions: This is, again, possible in a wide variety of languages, though not always as a default feature. For example, IPython adds this behavior to Python. Hot-reloading is not widespread because it often results in inconsistent program state.
Virtually all of CL's strengths are outmoded or defeated by giving the job of programming to a machine. It's like putting velvet inside your toilet tank: sure, it's fancy, but nobody benefits.
Even more importantly, though, the pool of available training data for CL is vanishingly small compared to other languages, which will increase the error rate dramatically. You should expect a lower quality of code for CL, and a high frequency of it being confused for similar, more popular languages like Scheme and Clojure. LLMs actually excel at Clojure, in part because its syntax is crunchier. All that sugar—applied consistently across the language, not sporadically in a rare DSL macro—helps the LLM keep track of what it's doing and where it is.
You asked Claude or some other agent to make your argument for you, and what you got was a well formatted pile of nothing. Bravo.
There's no such thing as "CL's standard library." I presume you mean the functions built into Common Lisp which provide basic functionality, but nobody uses "bare" Common Lisp any more than anybody uses bare C. The Quicklisp libraries for CL (among others) provide the modern utilities you seem to think CL lacks.