Hacker News Reader

Comment by vindarel | Hacker News Reader

The real "[Common] Lisp curse" is that once you taste it, there's no going back.

Other than that, the Common Lisp ecosystem is doing well thank you very much. Many contributors to SBCL, regular contributions to the important ecosystem libraries, vivid projects (Lem), new editors (mine) and plugins (OLIVE), some companies picking Lisp and somehow supporting the ecosystem (hosting conferences, contracting implementors). https://github.com/CodyReichert/awesome-cl/ · https://github.com/azzamsa/awesome-lisp-companies/ And yes, new vibe-coded projects too. Some are useful (ICL, cl-tuition…), some reinventing the wheel (badly) went nowhere. For some, we'll see.

View on HN

Since you mentioned the mine editor you must be aware of Coalton, but since you didn't mention Coalton I'll mention it here. Coalton is a Lisp library that basically adds static typing, type inference, and Haskell-style typeclasses on top of Common Lisp. (If you've never encountered type classes, then think of interfaces in the OOP language you know best. Type classes are what interfaces should have been: they can do everything interfaces can, and many things interfaces can't). Here's an example from the Coalton docs, which should be pretty self-explanatory; go read https://coalton-lang.github.io/manual/topics/whirlwind-tour/ if you want to see more.

    (coalton-toplevel
      ;; Type classes are defined with the define-class keyword
      (define-class (Eq :a)
        (== (:a * :a -> Boolean)))

      (define-type Color
        Red
        Green
        Blue)

      ;; Type class instances are defined with the define-instance keyword
      (define-instance (Eq Color)
        (define (== a b)
          (match (Tuple a b)
            ((Tuple (Red) (Red)) True)
            ((Tuple (Blue) (Blue)) True)
            ((Tuple (Green) (Green)) True)
            (_ False))))

      ;; Type declarations can have constraints
      (declare is-eql (Eq :a => (:a * :a -> String)))
      (define (is-eql a b)
        (if (== a b)
          "They are equal"
          "They are not equal"))

      ;; Multiple constraints must be wrapped in parentheses
      (declare double-is-eql ((Eq :a) (Eq :b) => (:a * :a * :b * :b -> String)))
      (define (double-is-eql a b c d)
        (if (and (== a b) (== c d))
          "Both pairs are equal"
          "The pairs are not both equal")))

For anyone who might not have encountered typeclasses before, the example might not be quite as self-explanatory as I thought it would be, so I'll explain that example a little.

The `(define-class (Eq :a) ...)` block is defining a type class called `Eq` with a type parameter named `:a`. Think of this as an interface that can be added after the fact. Most (all?) major OOP languages only allow you to declare interfaces when you declare a class, but in Haskell, and in Coalton that takes a lot of inspiration from Haskell, you can declare "interfaces" (typeclasses) on any pre-existing type, including ones coming from a library. Here, the `Eq :a` interface means that there must be a function called == (in Lisp even the operators are defined as functions) that takes two parameters of type :a and returns a Boolean.

`(define-type Color ...)` is defining a simple enum type. (You can do a lot more with it, of course, but this example is kept simple). Then `(define-instance (Eq Color) ...)` is saying "The type called Color is an instance of the typeclass (interface) called Eq". And since Eq requires a function called `==`, inside the define-instance block you have to define that function for the Color type. The pattern-matching should be simple enough that I don't think I need to explain it.

Now, the thing that makes this more powerful than interfaces is something I already touched on. Here the Color type is declared and then its typeclass instances are defined right away, which is the normal thing to do when you're creating a new type: keep all its code together. But if that Color type had come from another library that you imported, you would still be able to say "oh, and this Color type does implement Eq: here's the definition of == as applied to Color values". You're not restricted to only the interfaces that the library author thought to apply: you can take someone else's code and add interfaces to it! There have been several times when I really wished that were possible in C#.

Finally, the constraints before the => fat arrow are like declaring your function parameters as `public T isEqual<T>(T a, T b) where T : IEquatable`. This allows Coalton to catch, at compile time, any call to `is-eql` with parameters for which the `==` function is not defined.

There's plenty more at https://coalton-lang.github.io/manual/topics/whirlwind-tour/.

Thanks for the detailed explanation. I'm very familiar with Haskell, so this all feels very natural. How good is the type inference in practice? Is it a good as Haskell? And are there any places where you'd rather use vanilla common lisp?

Inference uses roughly the same algorithm and type system as Haskell (depending on what flavor of it... GHC has tons of extensions). It supports everything in the standard Haskell type system, as well as a few common extensions of Haskell, including multiparameter type classes, functional dependencies, etc.

About static typing and type inference: what does it do with code that it can't infer? It turns into a dynamic type ala Typescript, or it gives a type error?

I mean it must employ gradual typing, right? So that it can interface with existing code that is untyped

Coalton infers and checks all types for pure Coalton code; there's no such thing as a dynamic or untyped expression.

Code that is outside of the purview of Coalton—raw Common Lisp code—is run in explicit (LISP ...) forms [0] which require the user to annotate the type and they add dynamic type checks to ensure the enclosed code meets the contract the programmer specified (unless UNSAFE is used [1]).

[0] https://coalton-lang.github.io/manual/operators/lisp/

[1] https://coalton-lang.github.io/manual/operators/unsafe/

If I've understood https://coalton-lang.github.io/manual/topics/whirlwind-tour/... correctly (and please do read it for yourself because I might be misunderstanding it: I haven't used Coalton yet, only read the manual), Coalton will guess a type in some cases (such as numbers, but not only numbers). I don't know whether it gives warnings or errors for types it can't infer, but since it's based on Common Lisp I would assume it would give a warning and continue with an unknown type.

But there are definite advantages to having Coalton know your types, which is why they give you a `(declare foo Integer)` form. This doesn't compile to any code, it's a compiler hint that tells Coalton that it can assume `foo` is an int, not a float64/double, which allows it to pick at compile time which implementation of + gets used in `(+ foo 5)`.

The 2025 video introducing Coalton at https://www.youtube.com/watch?v=of92m4XNgrM gives an example of what Coalton can do with knowing types. Robert Smith (the presenter, and the primary creator of Coalton) gives an example of a Fast Fourier Transform function that uses generic numeric types so you can call it on any number type: float32, float64, int-modulo-a-prime, whatever. He then benchmarks it, and it takes about 1 second to run 2 million times. Then he adds the single compiler hint `(monomorphize)` above the function declaration. This tells Coalton "Hey, instead of doing a dispatch table lookup in this function and calling different + implementations based on the type of the parameters, I want you to create two different copies of this function, one that will call the specialized float32 math functions, and the other one that will call the specialized float64 math functions." (Or three copies if you also called it with your int-modulo-prime number type). This eliminates a dispatch-table lookup and allows the compiler to produce much more specialized code. It comes at the expense of larger binaries, of course: he's explicit about how this is trading speed for size, so it's an opt-in choice you make (by adding a `(monomorphize)` declaration above the function definition) rather than something that Coalton defaults to.

But I've digressed. Yes, I believe (though note my caveat about not having used Coalton yet) that it would use dynamic types for code whose types it can't infer. But I'm pretty sure it would also give you a warning. If it gives you an error, the solution is to add a `(declare [name] [type])` line in the appropriate place.

Lisp missed its timing. When it was above and beyond everything else and a totally different world, it was way too expensive and way too inefficient.

Today, when mainstream languages have stolen much from Lisp, the benefit of using a language where you can generally just add a gem, egg, or crate is much higher than the benefit of the one thing that is still unique to Lisp: macros. Reflection is inelegant as hell when you compare, but it will get you almost all the way macros do.

At the same time, typed languages have become much more like dynamic languages. The types have disappeared into var and let statements; they are now inferred rather than repeated. Pattern matching has been added, and more—without compromising the benefits for larger teams and larger code bases.

Purists will disagree, but I haven't seen a real world problem solved in Lisp that I couldn't also solve in other languages.

And yes, I am interested in being proven wrong. I want to know what kind of problems still exist that are that hardcore. But I suspect a big part of it is that those who code in this still think the "hello world" for Java looks something like this:

    public class HelloWorld {
      public static void main(String[] args) {
        System.out.println("Hello, World!");
      }
    }

when in reality it now looks like this:

    void main() {
      println("Hello World");
    }

and in C# it looks like this:

    Console.WriteLine("Hello, World!");

And comes with full first class support for Linux and Mac.

Lisp is an intellectual tower and has given an incredible amount to the programming community in terms of ideas and a playground for people to try things. I'm not denying any of that — it should be celebrated. But my thesis is this: most of that has been moved, copied, stolen, and adapted to mainstream programming languages.

>Purists will disagree, but I haven't seen a real world problem solved in Lisp that I couldn't also solve in other languages.

Turing completeness makes "I couldn't also solve" an impossibly high bar.

But if what you mean is, you haven't seen macros used in ways that make you wish your day-job programming language had macros, that's fixable.

Not GP and not Lisp programmer. But I'm curious about what you said. If you had to name one popular app or web service (>10,000 monthly unique users) that'd be much easier to clone in Lisp than in Python or Rust, specifically due to macros - what would that be?

I'm not active with any Lisp these days myself, either. Back in Web 1.0 days, when a lot of apps were transforming streaming rows of SQL results into grouped HTML entities, I used macros to implement something akin to SQL's LEAD and LAG, but at the application level. I don't have time, so I have to leave it as an exercise to the reader why it would take more verbosity to implement this in another language.

https://brl.sourceforge.net/brl_4.html#SEC31

Now, as a non-Lisper, I have to wait and hope the maintainers of programming languages I use will take useful syntax from other languages. Back when I was an active Lisper, I could take such syntax myself.

Is there any such syntax remaining? Sure, 20 years ago it was a pain to do manipulations of more than 1 element at a time. But nowadays everyone and their dog has some form of iterator combinators that make it a one liner. Even C++, although the line gets quite wide. Is there anything that, as of 2026, you seriously miss having in your day job language (and that language isn't Java)?

I'm having fun in TypeScript and only casually missing the capabilities of macros. It's Turing-complete, so doing the equivalent things is a simple matter of programming. And I'm almost always processing JSON structures, not SQL result rows, so I don't miss being able to write syntax like `sql-repeat` on a day-to-day basis.

Languages are no more Turing-complete than they were 50 years ago. If lack of Lisp macros was such a huge deal back then it affected day to day web development, then surely it must be affecting us all in this day and age too. Arguably, using JSON instead of SQL should make such macros even more important due to the unnesting of data we need to do. So why isn't it?

About today, JavaScript is good at referencing JSON. You don't need macros to make it better at it.

About back then, Perl/PHP/Python/Java/Ruby were never as good at pulling groups out of rows of SQL, but people could work around that by taking more time, writing more code, being more careful. So if you haven't seen macros used to make it better, you don't realize you're missing out on a huge deal. Maybe you just have a vague idea that things could be better, but you're too busy finding and fixing bugs to pursue this thought.

In other words, as of 2026, this phrase:

> if what you mean is, you haven't seen macros used in ways that make you wish your day-job programming language had macros, that's fixable.

is not true at all anymore? Or is it only true under very specific circumstances (if so, what are they)?

True if you would like syntax that doesn't lend itself to eager evaluation. In the `sql-repeat` example, `group-beginning?` takes an expression that can't be eagerly evaluated. It's evaluated twice, once for the current row and once for the previous row, and the result of evaluation is compared. It can't just be eagerly evaluated for the current row and the result used.

Also true if you want a shorthand syntax for defining a variable where the name of the variable is meaningful. JavaScript takes care of the most common case with destructuring assignment, but with macros you could make such syntax yourself.

Macros don't make it easier to 'clone' software. They make it easier to write software, any software.

And arguably harder to read and maintain other people's software.

Don't get me wrong I'm a macro fan. I've worked with some elegant codebases using metaprogramming but it's been challenging bringing people up to speed with super clear efficient - but novel - code,

Other projects that were just down the line Java boilerplate built on a well understood library worked just as well in other ways.

Personally I think reducing cognitive load is key, I've found people don't have the energy to work with clever code, even if it makes writing it a delight.

... and then llms happened, and I now don't write code at all but closely review a fire hose of mediocrity that gets the job done. I don't want that too magical.

> the one thing unique

it's the developer experience

(and the combination of all features, including homoiconic macros)

> a real world problem

You can solve anything with enough sweat ;)

One example? Routific's core algorithm is written in CL (source: its author on HN). Why not Java, like everybody on his field at this time? Because it was too tedious (edit: and we're not talking only about syntax) (there's a blog post somewhere). His prototype evolved in efficient production code, now the heart of the company.

> my thesis: most of that…

agreed on "most". Many features appear here and there in other languages. But there's the parts and the whole.

And the living platform ("stop writing dead programs"), still unique (with Smalltalk).

As big Smalltalk / Lisp / ML languages fanboy, I mostly agree with you.

In fact the main reason I hang around Java and .NET as my main tools, is that those development environments have taken many key features from those programming languages and development experience, to the point that where they still lose to them isn't that much relevant.

Additionally, now with AI code generation, the actual programming language matters even less, natural language can be translated to whatever programming language one feels like, at the whim of a Markdown paragraph describing the desired output, assuming it is supported on the model being used.

However it is kind of sad that we lost the last AI wave from Lisp/Prolog to Python, losing good machine code generation in the process.

And I have seen many real problems solved with Lisp, regardless, that is why commercial Lisps like LispWorks and Allegro are still in business.

> And I have seen many real problems solved with Lisp, regardless, that is why commercial Lisps like LispWorks and Allegro are still in business

Can you think of some domains where Common Lisp is a better choice than other languages? I have enjoyed Clojure for a lot of things, but I have not really found the features of SBCL useful for the kind of work I do.

For instance, restarts without unwinding the stack are cool, but for a server that's going to be running in production, it's not something I really leverage. I could use conditions to change the context of code called downstream, but I just haven't had a reason to do this yet.

Siscog, a Portuguese company well known in the community.

https://www.siscog.pt/en-us/

This is an old blog entry about their Lisp history, https://www.siscog.pt/en-us

https://www.siscog.pt/en-us/blog/35-years-of-lisping-at-sisc...

Then you have ITA Software bought by Google, and the reason they have Lisp style guide,

https://www.itasoftware.com

https://google.github.io/styleguide/lispguide.html

Autocad has used Lisp as main scripting language for quite some time, although they also do .NET as well nowadays,

https://help.autodesk.com/view/OARX/2026/DEU/?guid=GUID-037B...

Note that everyone talks about SBCL, but forget that the ones that survive the Lisp machines like experience are LispWorks and Allegro Common Lisp,

https://www.lispworks.com

Which if you want to have a taste how it looked like back in the day, some folks are trying to keep Interlisp-D memory from Xerox PARC alive.

https://interlisp.org

https://primer.interlisp.org/introduction

> I haven't seen a real world problem solved in Lisp

Bruh... Nubank is literally the biggest effing digital bank in the world. Famously built on Clojure stack. Just because you have not seen shit it doesn't mean it's not happening.

Apple, Netflix, Amazon, Walmart, NASA - they all use Lisp, and that's just the States. There are tons of European startups building on it.

> Lisp missed its timing.

It is literally timeless. Emacs just turned 50. Name a single half-a-century old software product that's being actively used, developed and improved. r/emacs subreddit gets daily, daily! updates of new Emacs package announcements.

> most of that has been moved, copied, stolen, and adapted to mainstream programming languages.

Totally. Except homoiconicity. The point of which the majority of programmers miss, misunderstand, or ignore. The bigger point programmers miss is that Lisp effectively proves that largely the syntax of programming languages doesn't really matter. What matters is the runtime. And Lisp today runs practically on every possible runtime. Meaning that to be a polyglot, you don't really need to know dozens of PLs, you can just understand homoiconicity and voila - you can practically ship software for any runtime. Syntax is the cheap part, and Lisp shows it well: Clojure on the JVM and CLR, Clojurescript on JS, Fennel on Lua, Hy on Python, LFE on BEAM, Jank on LLVM, etc. The surface stays the same, and the host changes underneath. Then you learn runtimes and type systems, which is the real work of being a polyglot. That is a big win. Most programmers spend years on syntax and then mistake it for knowing a language. Learn the damn Lisp. It is enormously practical.

> still think the "hello world ...

Who the fuck cares about intricacies? In pretty much [almost] every Lisp dialect it would be just:

(print "Hello, World!")

For EVERY different runtime.

Or just "Hello World" running under the repl

Reading the first paragraph of the article, I agree with them that Lispers don't collect as many dependencies.

But then once I read the second paragraph, I agree with you. Lisp is doing fine in terms of important ecosystem libraries. The article sets that as the context when it asserts as fact that "established libraries are incredibly stable, tested by hundreds of thousands of developers, included in thousands of CI pipelines and maintained by experts on the topic."

I don’t really see that either.

I see that sbcl itself is alive and doing rather well, but other than that the landscape is fairly grim.

Unironically the most successful modern day lisp is clojure, that mostly piggybacks the jvm and can reuse most java libraries and frameworks.

The thing about lisp, it’s that it’s fairly expressive. You only need a few foundational libraries (mostly algorithms) and it’s very easy to build on the rest. In something like Python, or Go, once you define a conceptual model in a library, you need another library for the glue code to bind it to another ecosystem. In Lisp, almost everything is using the basic list, alist, and plist,…

So you design from the core logic and write shim to external dependencies. Instead of bringing deps from the get go.

> You only need a few foundational libraries (mostly algorithms) and it’s very easy to build on the rest.

Yeah but i don’t want to. Let’s say i need to connect to rds using iam authentication.

I don’t want to write code for that, i want to use a library.

I don’t want a library that works with chicken scheme but not on sbcl and maybe on cmucl.

I know i can, i don’t want to. I want to reuse code written and maintained by other people.

> I don’t want to write code for that, i want to use a library

All the people that had that need wrote code for that. And I guess they don’t want to do unpaid work by providing a full fledged library.

> I know i can, i don’t want to. I want to reuse code written and maintained by other people.

Then I guess Lisp is not for you.

> Then I guess Lisp is not for you.

Aaand back to square one. Go tell to most of the industry and you get the lisp curse.

Thank you for proving me correct.

Given this elitist mindset of the lisp community, no wonder there’s a thing called “lisp curse”.

Lots of people have used lisp, scheme or scripting languages and never go back. Lisp was created in the 50s, if it converted everyone it would have done it a long time ago.

I don't think these 'most people' you anecdotally cite have gone deep enough into Lisp to realize what it's all about, and why it turns users who do taste real Lisp into Lisp fanatics.

You probably have no idea how much Lisp is out there in real, production systems. Just because the majority is required to be on Python, doesn't mean it's the best stack for solving problems. Gathering language stats for Lisp is also challenging, because it's not a single PL - it's a whole family of dialects. And these dialects and communities are absolutely thriving. Modern Lisp landscape is very, very different from LISP you're talking about (invented in the 50s).

I just wanna throw myself in here and get some advice. I’ve started using lisp recently mostly for emacs configuration but also doing a bit of recreation game programming in Fennel. If I wanted to learn a lisp for general programming/application stuff like writing a shell, a compiler, something more user facing, what would be good to check out?

It doesn't matter. Just start with a Lisp, any Lisp. Grok the idea of being REPL-driven, pick some structural editing idioms. That's all you need. Then, you pick a runtime for your needs. Depending on the runtime semantics you can choose a Lisp dialect for that runtime. Pick up some Clojure, it's enormously practical for any kind of data manipulation and analysis - small or big data. I don't even use jq anymore - studying http response in Clojure REPL is so much more convenient - you sort, filter and group data anyway you like.

I prefer the schemes.... Chicken scheme for standalone programs, s7 for embedding into larger systems. They're simple and easy to mold to whatever shape you want in my experience

That's kinda the problem of Lisp curse. You have several hundred slightly incompatible dialects instead of a one good language.

It's akin to how Linux isn't a OS but a family of OS with same core.

In practice, it is exactly the opposite of a "curse". From many practical points of view, when you actually use it, it feels and behaves like "one good language". You probably have little idea how jaw-dropping it feels when you write the same piece of logic in Clojurescript, and it seamlessly runs on both JVM and Javascript - completely incompatible platforms. I have not seen this kind of code-reuse even with Node, where the runtime is basically the same on both sides, but you still have to write code for them separately.

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.

Your entire rave sounds like exactly like a NixOS heavy user ranting about the greatness of flakes and immutability.

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.

Fair, enthusiasm isn't evidence. But adoption isn't either. Javascript took over because browsers shipped it. Python took over through universities and numpy. Neither won a contest on language design.

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.

Not to mention this very web site.

You probably have no idea how much Lisp is out there in real, production systems.

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.

> 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.

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.

Public GitHub repos and job ads measure open source and hiring. They miss private production code.

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.

> This is like when people say haskell is about to take over

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 never said Clojure or Lisp is "about to take over",

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.

> 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.

You forgot QuickLisp+Ultralisp, which is like PIP and PIP with daily builds or whatever it's called in Python.

I keep hearing this, but not really seeing it.

I've used more Rust tools, and jobs are outside few niches non-existent.

I've been mostly working in Clojure shops since 2015. I've changed multiple roles, different companies, dissimilar domain spaces, moved across the states. Never had a problem finding a job. My problem is the opposite - I kept getting offers for dealing with Clojure, only because I already have a track record.

Not recently though, right now it seems the market has just been completely obliterated and it is hard to find any kind of job, regardless of the tech stack.

Not my experience. I’ve played around with Common Lisp, Clojure, Scheme, Chicken, even wrote my own Lisp in C++. I’ve really wanted to like it, but it never stuck.

Also, the whole cult-like attitude from a number of people in the Lisp community was a big turn-off. All that “if you don’t get Lisp, you’re not smart enough, haven’t got enough experience, or just haven’t tried hard enough” BS gets pretty tiresome. Lisp is really simple. There isn’t much to “get”. Haskell/LEAN was much harder for me to “get” than Lisp. And LEAN absolutely blew my mind. Lisp didn’t.

Reply on news.ycombinator.com