It's akin to how Linux isn't a OS but a family of OS with same core.
And you haven't even seen the Clojure<->C++ interop in Jank. Anyone who has even the slightest clue of what's up says this is some kind of blackmagicfuckery.
I mostly don't use Lisp for work; we have some Clojure services, but they rarely require any attention - mostly when we need to bump dependencies. But I use a Lisp for personal stuff and I switch between different dialects multiple times a day - Elisp, Babashka, nbb, Fennel, Jolt, Jank - and the overhead is virtually none. I can't say the same thing about switching between JS/TS, even though I have used them for far longer than any Lisp.
And I am left wondering if it is that great why didn't it take over. I think you are ignoring some minor things that make it unpalatable for the most programmers.
Your comment to me sounds ironic because I don't even use Nix. I manage all my dotfiles in a single org-mode file and tangle them from there. It takes a few minutes to bootstrap a machine from scratch and makes my systems semi-immutable.
Comparison with nix on the surface sounds fair. Nix has steep learning curve, but most users once learn it, stay in it. Same can be said about Lispers - I have never met a person who wholeheartedly dove into e.g., Clojure and ever said it's [widely] impractical. There's unavoidable pain of getting into both, but the difference is where the pain sits. With Nix, much of it sits in the language and tooling: an untyped, lazy language with cryptic errors. With Lisp, the language is the simple part, and the cost is unfamiliarity and the ecosystem. Lisp's core is small enough to explain on a napkin, Nix's isn't.
> ignoring some minor things
I am not ignoring them, I speak from my heart. I know first hand how pretty much every mainstream popular stack lies to you about its own complexity. Neither Python nor Javascript are simple, small language ecosystems and I say that with full confidence after decades of using them. There's a real, practical wisdom of Rich Hickey's "simple vs easy" distinction and majority of programmers either don't know, don't understand, or don't care.
Gonna pushback on this. Adoption is proof of fitness to purpose in the Worse is Better way.
> Nix has steep learning curve
Not what I meant. I meant more in praise vs. how little you can see it in the wild.
> I am not ignoring them, I speak from my heart
I believe you speak from the heart, the same way I believe NixOS people speak from the heart. Or OpenBSD enthusiasts. The issue isn't the passion, but the way that passion biases you to overlook some corner.
I suspect in Lisp/Clojure case it's the lack of a large community and performance issues. Either the community is uninterested in making Lisp fast, too splintered or ignoring benchmarks.
We really do have a good idea because we can see how much every language is used on github and we can see bulk job listings on the internet.
Just because the majority is required to be on Python, doesn't mean it's the best stack for solving problems.
So which is it? Secretly popular or it doesn't matter that it's unpopular because it's so great anyway?
Gathering language stats for Lisp is also challenging, because it's not a single PL - it's a whole family of dialects.
If you take them all together, they still don't amount to much.
Modern Lisp landscape is very, very different from LISP you're talking about (invented in the 50s).
The old lisp landscape actually had some people using it.
It might be time to accept that most experienced programmer have heard of and used lisp or a variant at some point and it just didn't offer a real pragmatic advantage. It was very influential when the alternative was putting in assembly instructions using their hex codes, but modern languages have adopted all the best parts. The parts that are still unique like s-expressions, macros and 'code as data' haven't really paid off as much as people like to pretend. If you have every program writing their own crazy DSL, things get very squirly very fast, because every program becomes it's own niche language.
Mixing 'code and data' is the same thing. The key to simplicity is to use simple straightforward data structures and keep the data and execution as separate as possible because data is static and easy.
It has been 70 years and many ideas were hugely influential while some others ended up doing more harm than good. People thought inheritance was a great idea for 20-30 years too and we're still trying to fix that damage.
Public GitHub repos and job ads measure open source and hiring. They miss private production code. Nubank runs a bank with 100M+ customers. Google Flights grew out of ITA's Common Lisp engine. Those don't show up much in either metric.
Just, spend a minute looking at Nubank's numbers. It is the biggest digital bank in the entire world. They grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. For JPMorgan (just for low-key comparison), getting to their ~80M customers took around 150 years and dozens of acquisitions. It's not totally fair, because I'm handwaving assets here and other things, but seriously, how can this story be just ignored?
> So which is it? Secretly popular or it doesn't matter that it's unpopular because it's so great anyway?
Both. "There's more than the stats show" and "popularity doesn't measure fitness" don't contradict each other.
> The key to simplicity is to use simple straightforward data structures
You're reciting word for word the Clojure philosophy. Rich Hickey's "Simple Made Easy" talk makes exactly your argument.
> they still don't amount to much.
Go check Github Language stats and see where Emacs Lisp sits there. And let me remind you, Elisp is not a general-purpose lang, it was made for one and single objective, it's an effing text-editor configuration tool. Once again, r/emacs gets daily announcements of new Emacs packages. I'm not even exaggerating, every single effing day there's someone posting about a new package. Are you seriously not curious to see who the heck all these people?
> It might be time to accept that most experienced programmer
I think you seriously need to study the demographics of Lisper communities. Maybe log into Clojurians Slack, or watch some talks from Clojure conferences. Majority of them are surpassingly experienced. Over 95% of them are bona fide programming language polyglots. Most of them either borrow ideas from other languages into Lisp or take what they learned from Lisp into other languages. They rarely bash on specific PLs, because the choice of a language for specific scenarios largely doesn't matter, they understand that. They are not language fanatics. Neither am I. I'm not telling you to switch to my "beloved language". Because Lisp is not a language. Lisp is an idea. And it is a very much a brilliant one.
> If you have every program writing their own crazy DSL
> Mixing 'code and data' is the same thing.
"Code as data" doesn't mean mixing data with execution. It means code is written as ordinary data structures, so tools, editors and the program itself can read and transform it trivially. Languages without it still build DSLs. They just put them in YAML pipelines, JSX, HCL, decorators and annotation processors, and each one needs its own parser and tooling.
> modern languages have adopted all the best parts.
They adopted GC, closures and FP idioms. Most didn't adopt connecting to a running process and redefining one function while it runs, or structural editing. Those still change how the work feels day to day.
> It has been 70 years
Yes! That's the point. Great ideas are timeless and the grand idea of Lisp as a practical notation for lambda-calculus is timeless. Even though it was not initially designed as a notation for lambda calculus, the way how it fits almost purely incidental. McCarthy invented a language and, by accident, found inside it a minimal self-describing core. That core is the timeless part, and it stays timeless because it was found, not designed. Whether anything in mathematics is truly "discovered" is a philosophical question, but Lisp is one of the stronger cases for saying so.
You're basically fighting with me if math still matters. Dude, of course it fucking does.
Not really, because if companies use it they will mention it when hiring. It isn't back up by any real information. You're basically saying that all data says the opposite, but it's used a ton because of the one example company. This is like when people say haskell is about to take over because someone at facebook used it for an email filter. Everyone gives the same exact example. Every popular language has about a million examples.
Then you are trying to argue that customers or growth of one company has to do with language adoption. Do you realize that this seems like a desperate backwards rationalization of what you wish was true?
watch some talks from Clojure conferences
I have, they are obsessed with the rabbit hole of language pagentry and never seem to end up solving real problems. It's all about more and more complex language mechanics and labels of complicated techniques.
Both. "There's more than the stats show" and "popularity doesn't measure fitness" don't contradict each other.
Saying it doesn't matter that it isn't popular contradicts it being popular.
Do you know where emacs lisp ranks? 49th, behind a half dozen languages I've never heard of and configuration languages.
Most didn't adopt connecting to a running process and redefining one function while it runs Those still change how the work feels day to day.
Agreed
Great ideas are timeless
Agreed, that's why lisp has been so influential. That doesn't mean it is objectively a good choice by today's standards.
the grand idea of Lisp as a practical notation for lambda-calculus is timeless
Maybe, but the truth is no one cares about that because it doesn't mean anything to productivity or better software.
You're basically fighting with me if math still matters. Dude, of course it fucking does.
This is a nonsense statement that doesn't relate to the conversation. You're giving something a label that no one is asking for then saying the label is super important. No one cares about this, people can already do what they want.
I never said Clojure or Lisp is "about to take over", besides you're trying to use one spam-filter system inside a PHP company example, against CircleCI, Metabase, Walmart, Grammarly, ITA/Google Flights, Cisco, Rate.com, Funding Circle, Netflix and bunch of other teams that use it in production.
> I have, they are obsessed with the rabbit hole of language pagentry
Just a random example from Netflix guys: https://www.youtube.com/watch?v=gJ9UZlr6C6M
There's tons of different real-life use case talks. From Boeing/Embraer, from Funding Circle, from CircleCI, from tons of smaller startups running things on prod. You're just insisting of something you haven't even bothered to give a critical look at.
> That doesn't mean it is objectively a good choice by today's standards.
Okay, tell me more about "today's standards". What do you mean? No language is "objectively a good choice". A choice is good or bad for a team, a problem and a set of constraints.
It is a great choice for specific use cases. Fintech startups notably finding that to be very true.
> it doesn't mean anything to productivity or better software.
Clojure's immutable data by default rules out a whole class of concurrency bugs, and I already gave you the real-world example: Nubank scaled to thousands of engineers on Clojure and Datomic. That is a large bet on the language at a large scale, but you're just choosing to ignore that. I get it, every niche language has its "company X uses it". But once again, I'm not advocating for a single PL specifically. I'm preaching the idea of a language. The idea you're just outright dismissing because "it would have converted everyone a long time ago."
I've been working in this field for decades. I have gone through over a dozen language stacks: different paradigms, tons of tooling, techniques, patterns, hype cycles and silver bullet calls. If I've learned anything, it's that the majority is not only not always right, but in most cases it is flat-out wrong.
You don't have to trust me on this (some rando on HN), just listen to renowned CS veterans with big names - Guy Steele Jr., Alan Kay, Sussman, John Carmack, Crockford, Yukihiro Matsumoto, Paul Graham, Uncle Bob, Steve Yegge, Dijkstra, Brendan Eich, Karpinski - there are tons of names who'd agree that Lisp is an everlasting idea.
Lisp endures. It is thriving; there are new Lisp dialects coming out every few years. Some of them are serious tools, not toys. You can realistically run Lisp on pretty much any platform today.
I'm not suggesting everyone should just drop whatever they use and switch. I'm just saying there are some ideas that are worth understanding and your view on where Lisps stands today is misguided.
> This is a nonsense statement that doesn't relate to the conversation.
I.e., "lambda-calculus doesn't help anyone ship software". Yeah, maybe you're right. Yet it is still in there, whether we want it or not - it explains why the software we ship behaves the way it does. So maybe it's worth understanding the language that explains it best.
I didn't say you did.
CircleCI, Metabase, Walmart, Grammarly, ITA/Google Flights, Cisco, Rate.com, Funding Circle, Netflix and bunch of other teams that use it in production.
So which is it? It's popular or it's not popular but popularity doesn't mean anything?
Also naming a bunch of big companies doesn't mean much. When there are 10,000 employees, a few people are going to do something with niche tools. That isn't what these companies were built on and it's just a cheap use of their name. Again, it's like haskell people saying, "no on uses it? ever heard of facebook??" and it turns out to be one small program over the last 25 years of thousands of programmers' work.
Okay, tell me more about "today's standards".
Maybe you should tell me, because your comment is basically an appeal to authority without real numbers to back it up. You aren't talking about crucial features much or why you even like it.
Clojure's immutable data by default rules out a whole class of concurrency bugs
In practice this ends up being a feature with silver bullet believers like haskell's lazy evaluation, but when people try to make it work in practice the performance hits and awkwardness just don't give any benefits because you're fighting how a computer works, and if you really need it it can be replicated and used in specific situations. You can already make things const in system language and you can make structures and architectures that rely on copying data for certain parts of parallelism.
I've been working in this field for decades.
So have all the people not using lisp.
just listen to renowned CS veterans with big names
Listen to them say what exactly? You just listed a bunch of names as if that somehow makes a concrete or technical point. Most of those people don't ever use lisp in the first place so I'm not sure what this is supposed to say. "Uncle bob" is a buffoon snake oil salemen that knows less than nothing.
Lisp endures. It is thriving
Then why is the most popular lisp emacs lisp, which is less popular than 'vim script', starlark, gherkin, solitidy etc.
https://innovationgraph.github.com/global-metrics/programmin...
there are new Lisp dialects coming out every few years
Not sure this has accomplished much.
your view on where Lisps stands today is misguided.
I don't think it is. Everything points to it being influential but not used. After 70 years it might be time to accept this reality.
I think you're confusing my pragmatism for an enthusiasm of a misguided novice. I agree, sometimes you have to let it go, and I have. I started my coding journey with BASIC, in college I learned Pascal, C and Assembly, then Turbo Pascal, then later Delphi. You might be too young to remember how huge Borland was back then and I used their tech profusely. There was a period where I coded in Actionscript and VB, picked Macromedia, started making web-pages. I even worked in some esoteric language where all the operators were in Russian - I was working on a ERP system in Dubai with my Slavic friends. Then I picked some Perl and PHP. Following Heilsberg's work on Pascal, I went to .Net, when the guy moved from Borland to Microsoft. I switched from VB to VB.net, then to C#, I picked up some F# later. I developed games for Silverlight, remember that one? I was an early adopter of Typescript, forcing my team to switch from their beloved Coffeescript, that was at the time when GitHub in their style guide was explicitly asking to use Coffeescript for new projects instead of JS. I tried almost every available altJS option - Livescript, IcedCoffescript, Purescript, ELM, Reason, Fay, Haste and GHCJS. I was heavily invested into CLR only later to realize that it started feeling like a mental prison. I switched to Python on the backend. That's when I first time saw Clojure and blindly rejected it - it looked too weird. I then learned some Haskell, tried Idris, did Ruby, Golang, etc. etc.
Anyway, the point I'm trying to make - there are numerous tech pieces that I have completely parted with, with absolutely zero regret. Some pieces still remain practical - they simply work. I don't miss Pascal, Perl, Ruby or PHP. I'm a bit sad that Elm never took off, it was nice. Yet I don't see any reason to bury Lisp. It just works. It remains an enormously practical tool with zero meaningful alternatives.
I can tell you with conviction that using babashka for bash-scripting, or nbb for node stuff like simple web-scrapers is far, far better experience than the alternatives. Reducing huge Lua boilerplate to a five-liner Fennel macro feels liberating. Building web-apps with Reframe (today I'd use Datastar) felt like playing videogames. I stopped using jq for analyzing request data, Clojure REPL for digging through data is much simpler, faster and feels less confusing to me. And nothing, just nothing even remotely comes close to what I do and can do with Emacs. That didn't come out of nowhere - I was an IntelliJ power user for almost a decade, and used tons of different text editors and IDEs - from Eclipse to Atom. I still sometimes open VSCode and reach for Neovim in the terminal. I know what I'm talking about.
Trust me, another 50 years will pass, yet Lisp will remain. I can clearly see that; the idea of Lisp is simply way too practical to die. Would it ever become popular in a big team setting? Nobody can predict that. Perhaps it never will. Maybe there will be new Rusts, Kotlins, Elixirs and ML-like things, with Lisp carrying on in the shadows.
It's great that you have conviction but no matter how forcefully you say something this seems like your own personal journey to becoming obsessed with lisp.
That's fine, but it doesn't mean it is being used. Listing people and companies and languages with no context isn't real data.
Trust me, another 50 years will pass, yet Lisp will remain. I can clearly see that;
It has been 70 years and plenty of ideas have remained even though the actual languages are niche. You seem very confident that you can predict the future. Does this future predicting ability apply outside of 70 year old computer languages?
the idea of Lisp is simply way too practical to die.
The idea didn't, it's in the languages people use.