[abetusk]

There are many articles extolling the virtues of Lisp. I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages.

Articles like this, and the PG articles it references, amount to "if you know, you know". I understand the appeal and I understand the explicit and implicit arguments this article is making.

Computer programming has matured quite a bit in the past 60 years. I would like to see more articles that are more considered in their examination.

[coffeemug]

As a language Lisp is great (though the ecosystem is limited). It has two flaws-- it's very open-ended so unless you're talented and disciplined you can fall into a rabbit hole of hacking fun Lisp stuff and not actually getting any work done. Other languages have this problem, but Lisp I think more so.

The second flaw is that it eats perfectly capable minds for years and the results don't justify the time investment. Python or whatever is fine. I wish I took most (but not all) of the time I invested in Lisp and put it into something else instead.

[vkazanov]

Heh, i want to both disagree and agree.

I started with pascal and then C++. And then discovered Emacs and Lisp. Boy, that was a revelation!

Never ever in my life shipped a line of lisp code to production. My real life code was always Python or C++ or Java or C. All of my lisp was toys and emacs tweaks (50k loc in my config!).

But most of production code is gone from my life. I am a mid-level engineering manager now. I mostly write texts, or messages, or emails, or slides... and still use emacs and lisps for fun and profit and competitive programming.

Not a single production-grade lisp LOC in 20+ years. But, OTOH, i contributed to emacs, tinkered with compilers and interpreters and prog. lang. internals - all because Lisps made it interesting for me.

And, in a way, this brought me closer than ever to the job of my dreams: i work for a major player in static analysis space.

So yes, you are right and wrong at the same time.

[iLemming]

> programming has matured quite a bit

Your wording sounds like it implies that Lisp "got stuck" somewhere in the past, no?

Clojure, Clojurescript, Clojure-Dart, Fennel, Jade, Jank, Jolt, Coalton - these are relatively recent (and still developing) languages, and this is just off the top of my head, there are so many more.

Lisp is not a programming language (in a sense), it's an idea. It influenced pretty much every single PL we use today and continues to do so. You can't really "level-heatedly" criticize an idea, it's like criticizing I dunno, group theory. You can though debate about merits of a specific implementation of it.

[throwaway81523]

> Your wording sounds like it implies that Lisp "got stuck" somewhere in the past, no?

Pretty much. See pg's famous "Blub Paradox" where he sees Lisp as the top of a tower of lesser languages. He doesn't recognize that Lisp might at best be called a limit ordinal, to use math jargon. That is, Lisp is just another Blub, and the Lisp zealots haven't figured that out.

You don't necessarily want to keep going further and further up, of course. Lisp still has fascination. But e.g., in Common Lisp (I mean just the stuff in the CL spec, no ad-hoc extensions allowed) you can't write anything resembling an OS. You can in Scheme, using continuations to handle process switching.

Going further up, Lisp doesn't make it easy to ensure the absence of particular behaviours in a program, what TAPL calls the purpose of a type system. Tony Morrison has a semi-realistic example of what static types can get you:

http://blog.tmorris.net/posts/understanding-practical-api-de...

Link still works but TLS certificate expired in 2025, tsk tsk.

[hajile]

Your lisp criticism is orthogonal to the idea of lisp itself. Lisps like Coalton (lambda calculus) or Shen (sequent calculus) are strongly typed.

AI is an interesting point too where being closer to a raw AST is likely an advantage because it can focus more on the semantics instead of the syntax.

[throwaway81523]

You can wrap parentheses around anything and call it Lisp, but I specified Common Lisp and pg's article clearly wasn't contemplating anything like Shen. Surface syntax is near irrelevant though.

[iLemming]

I feel you're now contradicting your own statements now. You said: "[maybe] Lisp is just another Blub", but when pointed out that Lisp (and Lispers) is evolving, you're saying "pg clearly meant [the other Lisp]"...

Of course we're not talking about "parenthesis". Clojure even added square brackets for arguments and destructuring, it's not about the syntax, I agree on that.

[hajile]

Last I checked, both of these were built on top of Common Lisp/SBCL.

[iLemming]

pg's notion was psychological, not about languages per se: a programmer sitting in language X can't perceive power above X, only below. It's about a fixed vantage point.

Your "Lisp is just another Blub" would be true if Lispers were stuck looking up from Lisp-as-it-was and failing to see higher. If Lispers were trapped in the Blub position, they couldn't have deliberately imported ideas that sit "above" classic Lisp. But they keep adapting: Clojure added persistent immutable data structures; brought CSP/channels; introduced structural contracts like Spec and Malli. With Coalton and Shen they are explicitly reaching for the static-types level you say they can't see. Racket's whole "language-oriented programming" perhaps a level above any perceived Blub.

Maybe what you see ain't a Lisp ceiling? Could it be that some powers must live in the substrate - and Lisp's distinctive traits are precisely what makes building that new substrate cheap?

[throwaway81523]

I'm unfamiliar with Coalton but the Blub article describes the proverbial smug Lisp weenie. I'd agree with you that #notalllispers.

[iLemming]

Most Lispers I met do actively write in multiple languages all the time. They tend to borrow ideas from other PLs instead of loathing everything else that's not their favorite. They prefer Lispy syntax, but won't reject a language to achieve a goal - they'd pick everything - runtime, tooling, etc. and try to find a Lispy syntax that sits atop. While preserving all the remaining semantics. And then they'd argue that syntax does not make a language. Perhaps, Lispers are the largest demographic of polyglot programmers in the global community.

[gf000]

What idea? S-expressions?

Because that's all these languages share. What's common in CL and Clojure? They are as dissimilar as C and Scala.

[iLemming]

> What's common in CL and Clojure?

homoiconicity, macros, functional bias, REPL - to count just a few.

[gf000]

I would argue the functional bias when you have so much mutability.

Also, only the first one is remotely unique.

[iLemming]

Well, Haskell/OCaml campers would probably say "it ain't FP, like at all, rofl..." Truly, it's absolutely pointless mental exercise to cherry pick features of any given PL and compare with another one, with no regard to overall experience (which often is very subjective).

Switching between different Lisp dialects is far less mentally taxing, even when they operate in completely dissimilar runtimes. I have seen days when I needed to jump between CL, Clojure, Fennel, Elisp and Janet and from all practical points it felt like almost using the same language everywhere. While switching even between JS and TS is enormously vexing for me in comparison. Although I have programmed in both for far longer than any Lisp.

[lenkite]

> I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages.

Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.

[Jtsummers]

And it remains in a state of almost getting to the point of generic collections (like C++, Clojure, many others) using the standard functions, but not quite getting there. There are functions (not generic functions) which operate on sequences, but no standard way to extend what types are considered sequences (as one example). It makes sense that the 1995 version of the spec would be incremental, but without a further development (or consensus amongst the implementations if no official standard) it's difficult to continue moving forward to make better use of the language's generic function capabilities.

That's where Clojure, Julia, and many others have advanced beyond what CL (by the standard) provides. The language needed at least one or two more standards to drive those features forward, but never got them.

[Pay08]

I don't quite understand what you mean by generic collections in this case. Do you want to restrict a list to only contain one specific type?

[Jtsummers]

I wrote that quickly and should have edited it for clarity. What I meant was a new collection type that could be treated as a sequence.

https://www.lispworks.com/documentation/HyperSpec/Body/17_a....

None of the functions operating on sequences are generic, so you cannot create your own type and do a `defmethod` and have them automatically adapt to it. And unlike `print-object` which gets used by format and print and others, there's also no "protocol" (or whatever term you like) generic function you can implement which will make your collection acceptable as a sequence.

You could build something like this, and maybe shadow the standard functions so that it's not a new set of functions from a user perspective, but it's a notable absence in a language with a rich OO system through CLOS. It makes sense that it wasn't in the original spec, but I still think it would have been something that would have been added if the development of CL (as a standard) had continued.

[Pay08]

Oh, I understand. For what it's worth, some implementations do have that as an extension, although I've personally never used it. See http://www.sbcl.org/manual/#Extensible-Sequences.

[tmtvl]

> The standard hasn't been updated since 1995

The latest finalised submission to the Common Lisp Document Repository (confusingly called CDR instead of CLDR) dates from August 4, 2013. CDRs are the equivalent to the SRFIs from the Scheme world. You could argue that they are not THE standard, but they are A standard. And considering the original standardization supposedly cost 400,000 USD (about 900,000 USD in today's money), I can see why there hasn't been another official ANSI standard.

[rmunn]

Since my job involves a lot of Unicode stuff, I personally would have been confused if it had been called the CLDR, thinking that it was referring the Common Locale Data Repository. (I have to look something up in the CLDR about once a month on average).

And since the Common Lisp Document Repository appears to have been created in 2006 (the first document at https://cdr.common-lisp.dev/index_files/final.html is a description of the rationale for its existence, dated August 2006) while the Common Locale Data Repository was created in 2003, the Common Locale Data Repository had the CLDR acronym first. So kudos to the Common Lisp Document Repository folks for not overloading the acronym but finding an alternative.

[lenkite]

I see. Wasn't aware of this. However, it does not appear that an official standard for concurrency exists within the Common Lisp Document Repository (CDR). To be honest, CL implementers should just solicit donations for producing a standard.

There are also other basic things needed for adoption - standard APIs for database providers, etc

[rmunn]

https://github.com/CodyReichert/awesome-cl lists some concurrency packages, such as https://github.com/sionescu/bordeaux-threads and https://github.com/sharplispers/lparallel, as being "so widespread and solid that they became community standards. You can't be wrong with them." I don't know enough to know whether or not they're right about those being widespread, but if that list is wrong then I'm sure someone will chime in to say so.

So while the official standard may not have concurrency, that does not mean that there isn't a de facto community standard way to do it.

[chamomeal]

CL may not but other lisps do. Clojure’s concurrency is just so hawt

[vaylian]

The lisp curse: https://www.winestockwebdesign.com/Essays/Lisp_Curse.html

[erichocean]

Here you go: https://www.marktarver.com/bipolar.html

It's been discussed many times on HN.

[dang]

and strangely relevant again in the age of LLMs - https://news.ycombinator.com/item?id=48126840

[pjc50]

There seems to be a Lisp .. handedness?

Certain people seem to find it mentally appealing. I would liken it to one of the really niche music genres. Only a small number of people like it, but they do so very intensely. The Stockhausen of programming.

That's basically all it is. A fandom. A remarkably enduring one, but not one which has ever broken out, and therefore is unlikely to ever do so. Now in an even worse position: if you are armed with an LLM and therefore uninterested in the code itself, why on earth would you direct it to write in Lisp?

[patrec]

https://www.tamaspapp.eu/post/common-lisp-to-julia/

[throwaway81523]

I mentioned this already but you might like: https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87....