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
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?
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.
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.
They do start out by self identify as a "vibe coder". Which is equally embarrassing. What follows is an enumerated list, which I assume they didn't write the contents of, and I don't care to figure out. I had a hiatus from HN for a little while due to these kinds of posts taking over, but the whole front page is just LLM kool aid stuff now.
Let’s be honest: Lisp is a language designed by and for elite hackers, not for the masses.
What do other people say about other languages?
Python is best for novice coders, machine learning, and versatility. [https://www.boot.dev/blog/python/c-sharp-vs-python]
Golang: Simpler and minimalistic language with fewer features, making it easier for beginners and experienced developers to learn and use effectively. [https://charleswan111.medium.com/java-vs-golang-a-comparative-insight-into-usage-performance-and-industry-preferences-533a24013230]
JavaScript is also considered to be more user-friendly and easier to learn than C++. [https://www.c-sharpcorner.com/blogs/cpp-vs-javascript-programming]
If one is allowed to compare apples and oranges, then surely one is allowed to compare oranges and apples.
Hey, are people not allowed to self select as smug Lisp weenies anymore? Even on HN?
What Lisp enthusiasts lost in terms of actual status in the programming world they make up for themselves in their niche corners and everyone is happy at the end.
Oh, they can do whatever they want, I just find it strange. With very few exceptions, people who are “elite” at anything don’t need to blog about their eliteness, their work speaks for itself.
Imagine for example Fabrice Bellard (too many amazing accomplishments to list here) posting that he’s an elite developer. That’s right, he doesn’t need to, everyone knows it already.
As far as Lisp programmers go, Joe is quite elite, though I suspect he’s got a twinkle in his eye when he says this, applying a bit of sarcasm. He’s been a Lisp programmer longer than most programmers have been alive.
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.
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.
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.
Do you really think current LLMs can implement a large application in C as securely as they can in e.g. Go? I will freely admit that I have not tried to do so but I have a hard time imagining it. Perhaps my biases are outdated...
> 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.
This sounds really really interesting. I don’t suppose you can share more about this?
If you write a harness in Lisp, you can easily access the running Lisp environment via tools, one of which can be a repl tool. This allows the model to do whatever it wants within that environment. Obviously, this is “dangerous” and should be sandboxed.
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.
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.
I hadn't heard of this issue with SBCL before so I went searching for it. I guess you're referring to this: https://log.schemescape.com/posts/lisp/sbcl-file-perf-window... That article points out that the issue arises only on Windows. Do you have any evidence of such an issue on Linux or other OS?
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.
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.
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.
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!!
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.
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.
I only touch some emacs lisp and never do Common Lisp
But seems years of coding experience make me think those tenets in the article reasonable
There are indeed elite programmers as I see in my career it’s rare also we do not need to be sad
Maybe it’s time to learn some Common Lisp given it’s a good day for exploration and prototyping
I find only the first reason convincing, and this would obviously be the case for any programmer, just as you choose to implement in a language best for the task at hand that you know well, you should choose to vibe code in the same way.
Of the other reasons - when he says
>Most modern languages force you to describe exactly how a machine should shuffle bits around.
he must mean something very differently from what I mean if I were to say shuffle bits around, because this is normally what I think most modern languages don't force you to do.
the elite thing seems not to mean much.
>Homoiconicity and the AST
maybe, I would expect predicting well known syntax would be easier for an LLM, but he says it's not. So... maybe?
>Macros as Context Compression
Wait, is the LLM generating macros? But LLMs have well known propensity to verbosity. That is to say in these other languages experts in those languages find the code the LLM generates overly verbose. But not in Lisp, or is it that he writes a macro and tells the LLM use that, but I mean other language experts can write a function and say use that instead of your more verbose methods?
>Superior Error Handling
shouldn't we have the LLM generate Erlang?
I mean I get the reasons to go off on how your language is superior and great and do the arguing about all sorts of features and I am all for Lisp or Scheme as maybe the greatest, but the language snobbery in support of LLM target choice just seems weird. Like arguing about why the cream filling in Twinkies is superior to that of Choko-Diles.
Maybe I am just not keeping up on the latest frontiers of language snobbery anymore.
It's a purely theoretical and speculative advantage as of now. Human lisper think in AST, that's something powerful, and it's reasonable to assume an AI could too, with benefits. But LLMs simply don't; not only they will occasionally mismatch parens, but they will dig themselves in a pit when asked to fix it. Stronger models miss far fewer parens, but that's most likely that they adapt better, not that they think in s expressions ASTs. But we could totally imagine transformer producing directly ASTs, and lisp is probably the best first target for that.
I've found macros and live programming to be much of the same: it'll do it when asked to, but is not particularly natural or apt at it. They can use macros well, but will rarely choose to write the correct macro when needed.
Live programming feel particularly ill-suited: multiplying small request with an accumulating context sounds like a sure fire way to explode your token budget. It does wonder for humans because we're able to compress our "context" on the fly. Context caching may mitigate all or most of it, but then it make compressing context less worthwhile. As much as I dislike it, LLMs are punch-card programs suited punch-card programming (write/read all in one go, then compile and execute); his entire training set is arguably punchcard, even from live programming languages.
My gut feeling is, this post is 180° wrong. LLMs are the exact opposite of "elite coders", they're perfect StackOverflow users:
* they memorize adapt and write back small-scale patterns very efficiently;
* they know widespread libraries inside out, and can learn others in minutes, even if their doc sucks;
* they often produce good results, because most of the time we write unoriginal code, which paraphrases something it already has dozens of versions of in their training corpus;
* but they're bad at seeing meaningful, non-obvious, simplifying abstractions, we really have to spoon-feed those to them;
* they _love_ verbosity, that's literally how they "think";
* they also love repetition: the other term for "repetition" is "patterns", and they're basically excellent pattern matchers.
So, Lisp is enjoyable for your typical LLM-complementary hacker, but not for LLMs. LLMs typically replace the kind of "non-elite" developers who hated Lisp, for remarkably similar reasons.
What I'd love would be an LLM trained to faithfully rephrase a "normal" program into Lisp-ish pseudo-code, that would make reviews faster, more reliable, more enjoyable. But hand-written code is going the way of hand-written machine code; let LLMs have what suits them best, and higher level tools for the more abstract jobs where we're still relevant, and that would be various forms of code reviews.
As for calling "elite" the kind of developer won't understand that development is a team sports, and that the proper tool is the one that fits the team, not their own peculiar quirks, I'm not going to address that, it isn't the keystone of his argument; but a lot could and should be said about that too.
59 comments
[ 0.23 ms ] story [ 20.9 ms ] threadAre there any programming/computer science greats that self aggrandize like this? Is it a cultural thing somewhere that I’m not aware of?
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.
What Lisp enthusiasts lost in terms of actual status in the programming world they make up for themselves in their niche corners and everyone is happy at the end.
Imagine for example Fabrice Bellard (too many amazing accomplishments to list here) posting that he’s an elite developer. That’s right, he doesn’t need to, everyone knows it already.
Less so with Clojure.
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.
This sounds really really interesting. I don’t suppose you can share more about this?
I'd be very interested in reading more about this.
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.
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.
I'm sorry you're scared by em-dashes. They were cool when I was young, alright?
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
There it is again.
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.
Of the other reasons - when he says >Most modern languages force you to describe exactly how a machine should shuffle bits around.
he must mean something very differently from what I mean if I were to say shuffle bits around, because this is normally what I think most modern languages don't force you to do.
the elite thing seems not to mean much.
>Homoiconicity and the AST
maybe, I would expect predicting well known syntax would be easier for an LLM, but he says it's not. So... maybe?
>Macros as Context Compression
Wait, is the LLM generating macros? But LLMs have well known propensity to verbosity. That is to say in these other languages experts in those languages find the code the LLM generates overly verbose. But not in Lisp, or is it that he writes a macro and tells the LLM use that, but I mean other language experts can write a function and say use that instead of your more verbose methods?
>Superior Error Handling
shouldn't we have the LLM generate Erlang?
I mean I get the reasons to go off on how your language is superior and great and do the arguing about all sorts of features and I am all for Lisp or Scheme as maybe the greatest, but the language snobbery in support of LLM target choice just seems weird. Like arguing about why the cream filling in Twinkies is superior to that of Choko-Diles.
Maybe I am just not keeping up on the latest frontiers of language snobbery anymore.
It's a purely theoretical and speculative advantage as of now. Human lisper think in AST, that's something powerful, and it's reasonable to assume an AI could too, with benefits. But LLMs simply don't; not only they will occasionally mismatch parens, but they will dig themselves in a pit when asked to fix it. Stronger models miss far fewer parens, but that's most likely that they adapt better, not that they think in s expressions ASTs. But we could totally imagine transformer producing directly ASTs, and lisp is probably the best first target for that.
I've found macros and live programming to be much of the same: it'll do it when asked to, but is not particularly natural or apt at it. They can use macros well, but will rarely choose to write the correct macro when needed.
Live programming feel particularly ill-suited: multiplying small request with an accumulating context sounds like a sure fire way to explode your token budget. It does wonder for humans because we're able to compress our "context" on the fly. Context caching may mitigate all or most of it, but then it make compressing context less worthwhile. As much as I dislike it, LLMs are punch-card programs suited punch-card programming (write/read all in one go, then compile and execute); his entire training set is arguably punchcard, even from live programming languages.
> shouldn't we have the LLM generate Erlang?
Unironically a good idea
* they memorize adapt and write back small-scale patterns very efficiently; * they know widespread libraries inside out, and can learn others in minutes, even if their doc sucks; * they often produce good results, because most of the time we write unoriginal code, which paraphrases something it already has dozens of versions of in their training corpus; * but they're bad at seeing meaningful, non-obvious, simplifying abstractions, we really have to spoon-feed those to them; * they _love_ verbosity, that's literally how they "think"; * they also love repetition: the other term for "repetition" is "patterns", and they're basically excellent pattern matchers.
So, Lisp is enjoyable for your typical LLM-complementary hacker, but not for LLMs. LLMs typically replace the kind of "non-elite" developers who hated Lisp, for remarkably similar reasons.
What I'd love would be an LLM trained to faithfully rephrase a "normal" program into Lisp-ish pseudo-code, that would make reviews faster, more reliable, more enjoyable. But hand-written code is going the way of hand-written machine code; let LLMs have what suits them best, and higher level tools for the more abstract jobs where we're still relevant, and that would be various forms of code reviews.
As for calling "elite" the kind of developer won't understand that development is a team sports, and that the proper tool is the one that fits the team, not their own peculiar quirks, I'm not going to address that, it isn't the keystone of his argument; but a lot could and should be said about that too.
... it took them up to item #3 this time? Usually i see this quoted as item #1