1. it violates normal syntax rules you have been practicing since you were 4 years old.
Lisp will say:
(+ (- (\* 3 5) 7) (/ radius pi))
but you are taught since 5:
(3*5 - 7 + radius/pi)
2. Humans are highly adapted to using language, and understanding language constructs such as implicit context rules. Humans reduce token counts and structure in favor of implicit rules and making common patterns shorter. Lisp makes them all explicit, which forces you to cope with way more tokens. Lexical binding was added to Common Lisp almost as an afterthought, and the way LET/LET* force you to add layers of nesting demonstrates that. Every time you assign a variable the 'modern' way, you have to indent another block of code.
A concrete example is introducing local bindings with actions in between. The thought is "calculate this, do something, then continue":
This is much closer to what is actually happening, and does not require you to understand scoping rules, but it's cumbersome and stupid.
LET* handles consecutive bindings, but here the actions must happen between them. You can use PROGN inside the initializers, or introduce dummy bindings for the actions, but either way you're restructuring a flat sequence to fit the binding syntax.
That's the implicit context I mean: the statement order combined with syntax rules of the language can supply the scope, without requiring a new enclosing expression every time you introduce a local. Lexical scope itself doesn't require this nesting to be explicit in the syntax of the language and it's not helpful for it to be.
3. So many inconsistencies.
Common Lisp uses alternating keys and values for property lists:
GETF puts the container first; GETHASH and ASSOC put the key first. ASSOC also returns the matching pair, whereas GETF and GETHASH return the value as their primary result.
4. What happens at COMPILE-FILE time is arcane and almost impossible to keep straight.
5. Common Lisp often feels designed primarily to implement Common Lisp, rather than to write useful application code. Its equality predicates are a good example: EQ, EQL, EQUAL, and EQUALP give you four fixed bundles of rules organized around Lisp's own representations.
Want arrays compared by content? EQUALP does that, but also makes string comparisons case-insensitive. Want objects compared by their slots? EQUALP does that for DEFSTRUCT instances, but not ordinary CLOS instances. Want to define what equality means for your class? None of these predicates is a generic function you can extend.
Checking something basic like "when do these two values mean the same thing?", requires a separate operation of your own. None of the equality operators do anything close to what someone might actually want, unless they happen to be implementing CL in which case they are exactly what you want.
Comparison EQ EQL EQUAL EQUALP
Lists containing (1 2) NIL NIL T T
List (1 2) versus (1.0 2.0) NIL NIL NIL T
Strings containing "Ada" NIL NIL T T
String "Ada" versus "ADA" NIL NIL NIL T
Same-type DEFSTRUCT instances, identical slots NIL NIL NIL T
Same-class CLOS instances, identical slots NIL NIL NIL NIL
No, Common Lisp was not Lexical from day one. You are not familiar with the history. It was more or less a merging of several lisp dialects each sponsored by a different lisp machine vendor. Many of those were primarily not lexically scoped, although Zetalisp did add modern lexical scoping by 1985.
Steele himself mentions the lack of lexical scoping in contrast to scheme. <a href="https://research.scheme.org/lambda-papers/lambda-papers-compiler-optimization.html" rel="nofollow">https://research.scheme.org/lambda-papers/lambda-papers-comp...
> I don't even want to waste my time to unpack.
It is typical for people who can't respond substantively to brag about how they could respond but imply their relative status makes doing so beneath them.
(local
(def user (find-user user-id))
(require-admin user)
(def report (build-report user))
(write-audit-log user report)
(def receipt (send-report report))
(record-delivery receipt))
What the hell is that supposed to be? It's not common lisp. `local` is not defined in CL, it is a keyword in Racket that does something like what you typed there, but not really the same.
Anyway I don't know what you are showing here but it's nonsense in every language I'm aware of.
<a href="https://www.lispworks.com/documentation/HyperSpec/Front/X_Mast_L.htm" rel="nofollow">https://www.lispworks.com/documentation/HyperSpec/Front/X_Ma... (no local there)
<a href="https://www.lispworks.com/documentation/HyperSpec/Front/X_Mast_D.htm" rel="nofollow">https://www.lispworks.com/documentation/HyperSpec/Front/X_Ma... (no def either)
> No, Common Lisp was not Lexical from day one.
The first edition of Common Lisp the Language defined the language as having lexical scope, with the option to create special variables with dynamic scope (so it had both). Unless you're referring to some earlier draft specification, it's hard to reconcile your assertion with the history of the language.
From page 39:
> - Variable bindings normally have lexical scope and indefinite extent.
> - Variable bindings that are declared to be special have dynamic scope (indefinite scope and dynamic extent).
OK, Common Lisp as described by the standardization process has always had lexical scoping, no argument there. Lisp, including the variants of Lisp that CL was largely derived from, did not always have lexical scoping.
So what you are saying is a lot like if I said "C++11 has ALWAYS had the auto keyword!". While I ignore the fact that C++ did not always have the auto keyword, and the repeated typing of the same type signature over and over was a major complaint about the language for over 20 years. Yes, it's true, but it's just ignoring reality and not informative to the overall point I was making, which was Lisp is clearly not designed to make lexical scoping 'nice', because lisp predates the use of lexical scope being the dominant way to do scoping. You can see that in the very conception of scheme, originally designed to be "Lisp but with lexical scoping".
Edit: corrected responding to the wrong person. For the record "Jtsummers" and "iLemming" do look quite a bit more alike than two random usernames!
I'll write a second reply, I don't normally do this but you completely edited your comment.
> Lisp, including the variants of Lisp that CL was largely derived from, did not always have lexical scoping.
Correct, but you specifically wrote about Common Lisp, thus my reply about Common Lisp, not Lisp (the historical category of languages or the older language definitions which used dynamic scoping rules).
>> No, Common Lisp was not Lexical from day one.
You were very explicit about the language version you were speaking about, as was I in my reply.
You are incorrectly presumptuous. Common Lisp had lexical scoping as a design requirement from its first technical meeting in 1981, three years before the language was published. <a href="https://dl.acm.org/doi/10.1145/234286.1057818" rel="nofollow">https://dl.acm.org/doi/10.1145/234286.1057818
<a href="https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf" rel="nofollow">https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf
Steele wrote the Lambda Papers in 1975-1980, before CL existed. They contrast Scheme with MacLisp, and Steele then brought Scheme-style lexical scoping into CL.
CL marks itself as different from its dynamically scoped predecessors.
<a href="https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html" rel="nofollow">https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html
> It's not common lisp.
It is, but you're correct, it's not core of CL, it's from ruricolist/serapeum - a widely known CL lib.
Ok, so the original question was "Why is Lisp so difficult to read?" and your answer is it's not, so long as you fix the things that make it difficult to read?
How does that help me read Lisp code more easily? When I open a file with Lisp code in it, I just say to myself "this would be easier to read if they used serapeum instead of writing it in normal idiomatic Lisp" and then it's easier for me to read?
You just used some contrived example to make it look harder to read, perfectly knowing that there are dozens of different ways to improve your specific snippet for readability, and I simply grabbed the first method I could think of. I can equally chose pretty much any PL and make it look very nasty, it's not that hard. "Readability" is not some intrinsic value of any language.
So in your mind assigning variables and calling functions is "contrived"? LOL ok
Stop threatening to prove me wrong and give it a shot. So far you have just said over and over "I shant deign to prove this wrong even though it is very easy to do so in so many way" then gave a bogus example and didn't address any of my points. You just keep saying "Nuh uh!"
What's there "to prove"? It took two people getting dragged into a downvoted and dead topic and meticulously fishing for references for you to finally accept that Common Lisp was never dynamically scoped - something you could do yourself, without wasting anyone's time. You perceive Lisp to be "cumbersome and stupid" and "inhumane" due to your own personal opinions. You just lack understanding of the mere idea of a homoiconic language and are pigheadedly trying to prove to the world that somehow it's not a good idea or whatever. Well, I can tell you this - nobody really cares. They're just your opinions; you're entitled to have them, just like I reserve the right to have my own.
Opinions don't mean shit unless they are supported by evidence, and Lisp has plenty of it. It has survived subjectivity for almost 70 years, and it's still thriving. Good ideas don't need to prove anything; they just exist. If you still cannot see the reasons for why so many people still choose to use it, I'm sorry, that's just dumb and nearsighted. And you don't really have to listen to me - try to find some renowned CS academics or big-shot programmers publicly bashing Lisp - you won't find many.
Yeah, right. The biggest digital bank in the world uses it. Nubank, using Clojure as their primary driver, grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. For JPMorgan (just for comparison), getting to their ~80M customers took around 150 years and dozens of acquisitions.
Netflix uses it. Amazon uses it. Apple uses it. Walmart built their billing system in it. Cisco's entire cybersec stack is on it. Even NASA uses it.
Let's see, how has it been "dying"? Clojure, Clojurescript, Clojure-Dart, Coalton, Fennel, Janet, Jank, Jolt, LFE, Joker ... and these are relatively recent additions. The amount of Emacs Lisp on GitHub alone should be at least surprising - go check the GitHub lang stats, isn't it weird - a non-general-purpose PL, that has one and only one intent, is among the top languages, why? Check the r/emacs subreddit - there are daily, pretty much daily announcements of some new Emacs packages. Who the hell are these psychopaths? Don't they realize that Lisp is "dying"?
You don't know jack shit about whatever you're trying to talk about, and you call yourself "a hacker"? Honestly, it's pretty sad when someone can't find the time and patience to learn an instrument and then blame their own failure on the thing. Rather pathetic.
Look at Clojure job listings. Over 80% are trying to hire people to port them off Clojure. The community is insular and not growing and has been shrinking for a decade while the rest of the industry has grown 5x.
McDonald's is the most popular restaurant in the world. Constantly growing, it's a name everyone knows. That's not my kind of food. I don't even consider it "food" really, I'd eat it only if there's no other option. Have you ever heard of Sobrino de Botín in Madrid? Probably not. It opened in 1725 and still serves good food. In my book, that's a success story.
I bet you have no idea what Emacs is for, what it is capable of; you probably think it's "a text editor", yet in experienced hands it simply destroys all the other alternatives, easily. TextMate, Eclipse, Komodo, Aptana, Zend Studio, Dreamweaver, Brackets, Atom, Sublime Text - each of them at some point in time was more popular than Emacs, most of them slowly disappeared, Emacs is still here, stronger than ever. That is a success story.
I guess you have techno-myopia, and just can't see past your own bubble - some ideas are simply timeless: Lambda Calculus, Relational algebra and SQL, Vim modality, Regular expressions and finite automata, Homoiconicity, Unix Pipes, Curry-Howard, Immutability, Garbage Collection, etc.
None of that will ever be affected by the industry trends and will always be relevant. Nobody can kill Lisp because it's not a concrete implementation, it's an abstract idea. Clojure won't ever die, it will simply transform into another kind of Lisp. Just like it emerged as a Lisp, built on top of other ideas. Newton's laws no need to be "successful", they seek no recognition, it's not a popularity contest. They are still relevant, even after Einstein's discoveries.
What's your goal here? To prove something to me? Buddy, I'm far beyond redemption - I've seen way too much crap, and I learned how to collect good ideas and put them to good use. I suggest trying something like that. Some ideas are worth attention.
I don't know what the heck makes you so angry; I suppose it's your own inability to look into a given idea and, with candid curiosity, attempt to see what it is about. Your views are one-sided. You should at least acknowledge that I have seen both sides of that coin and maybe, just maybe, there's some truth in my tale, despite of me being biased (everyone, almost always is).
ltbarcly3 · · focus · HN ↗
Lisp will say:
but you are taught since 5: 2. Humans are highly adapted to using language, and understanding language constructs such as implicit context rules. Humans reduce token counts and structure in favor of implicit rules and making common patterns shorter. Lisp makes them all explicit, which forces you to cope with way more tokens. Lexical binding was added to Common Lisp almost as an afterthought, and the way LET/LET* force you to add layers of nesting demonstrates that. Every time you assign a variable the 'modern' way, you have to indent another block of code.A concrete example is introducing local bindings with actions in between. The thought is "calculate this, do something, then continue":
In Common Lisp, a direct translation adds a level of nesting for each binding: This is much closer to what is actually happening, and does not require you to understand scoping rules, but it's cumbersome and stupid.LET* handles consecutive bindings, but here the actions must happen between them. You can use PROGN inside the initializers, or introduce dummy bindings for the actions, but either way you're restructuring a flat sequence to fit the binding syntax.
That's the implicit context I mean: the statement order combined with syntax rules of the language can supply the scope, without requiring a new enclosing expression every time you introduce a local. Lexical scope itself doesn't require this nesting to be explicit in the syntax of the language and it's not helpful for it to be.
3. So many inconsistencies.
Common Lisp uses alternating keys and values for property lists:
Association lists use a list of pairs: And LET uses two-element binding lists: Lookup conventions differ as well: GETF puts the container first; GETHASH and ASSOC put the key first. ASSOC also returns the matching pair, whereas GETF and GETHASH return the value as their primary result.4. What happens at COMPILE-FILE time is arcane and almost impossible to keep straight.
5. Common Lisp often feels designed primarily to implement Common Lisp, rather than to write useful application code. Its equality predicates are a good example: EQ, EQL, EQUAL, and EQUALP give you four fixed bundles of rules organized around Lisp's own representations.
Want arrays compared by content? EQUALP does that, but also makes string comparisons case-insensitive. Want objects compared by their slots? EQUALP does that for DEFSTRUCT instances, but not ordinary CLOS instances. Want to define what equality means for your class? None of these predicates is a generic function you can extend.
Checking something basic like "when do these two values mean the same thing?", requires a separate operation of your own. None of the equality operators do anything close to what someone might actually want, unless they happen to be implementing CL in which case they are exactly what you want.
iLemming · · focus · HN ↗
> Lexical binding was added to Common Lisp almost as an afterthought
Common Lisp was lexically scoped from day one. You're arguing about CL using Elisp's history.
And your "cumbersome and stupid" snippet is that, because, well you wrote it that way.
In modern Lisp dialect like Clojure it would look even more cleaner.Lisp is the language where you do whatever syntax is suitable for the task, yourself, in an afternoon. In Python you wait for a PEP.
ltbarcly3 · · focus · HN ↗
Steele himself mentions the lack of lexical scoping in contrast to scheme. <a href="https://research.scheme.org/lambda-papers/lambda-papers-compiler-optimization.html" rel="nofollow">https://research.scheme.org/lambda-papers/lambda-papers-comp...
> I don't even want to waste my time to unpack.
It is typical for people who can't respond substantively to brag about how they could respond but imply their relative status makes doing so beneath them.
What the hell is that supposed to be? It's not common lisp. `local` is not defined in CL, it is a keyword in Racket that does something like what you typed there, but not really the same.Anyway I don't know what you are showing here but it's nonsense in every language I'm aware of.
<a href="https://www.lispworks.com/documentation/HyperSpec/Front/X_Mast_L.htm" rel="nofollow">https://www.lispworks.com/documentation/HyperSpec/Front/X_Ma... (no local there)
<a href="https://www.lispworks.com/documentation/HyperSpec/Front/X_Mast_D.htm" rel="nofollow">https://www.lispworks.com/documentation/HyperSpec/Front/X_Ma... (no def either)
Jtsummers · · focus · HN ↗
The first edition of Common Lisp the Language defined the language as having lexical scope, with the option to create special variables with dynamic scope (so it had both). Unless you're referring to some earlier draft specification, it's hard to reconcile your assertion with the history of the language.
From page 39:
> - Variable bindings normally have lexical scope and indefinite extent.
> - Variable bindings that are declared to be special have dynamic scope (indefinite scope and dynamic extent).
ltbarcly3 · · focus · HN ↗
So what you are saying is a lot like if I said "C++11 has ALWAYS had the auto keyword!". While I ignore the fact that C++ did not always have the auto keyword, and the repeated typing of the same type signature over and over was a major complaint about the language for over 20 years. Yes, it's true, but it's just ignoring reality and not informative to the overall point I was making, which was Lisp is clearly not designed to make lexical scoping 'nice', because lisp predates the use of lexical scope being the dominant way to do scoping. You can see that in the very conception of scheme, originally designed to be "Lisp but with lexical scoping".
Edit: corrected responding to the wrong person. For the record "Jtsummers" and "iLemming" do look quite a bit more alike than two random usernames!
Jtsummers · · focus · HN ↗
Read the usernames, "Jtsummers" and "iLemming" don't even look alike.
iLemming · · focus · HN ↗
[dead]
Jtsummers · · focus · HN ↗
> Lisp, including the variants of Lisp that CL was largely derived from, did not always have lexical scoping.
Correct, but you specifically wrote about Common Lisp, thus my reply about Common Lisp, not Lisp (the historical category of languages or the older language definitions which used dynamic scoping rules).
>> No, Common Lisp was not Lexical from day one.
You were very explicit about the language version you were speaking about, as was I in my reply.
iLemming · · focus · HN ↗
Great. Arguing about "readability" with a dyslexic person. What could ever go wrong here?
iLemming · · focus · HN ↗
You are incorrectly presumptuous. Common Lisp had lexical scoping as a design requirement from its first technical meeting in 1981, three years before the language was published. <a href="https://dl.acm.org/doi/10.1145/234286.1057818" rel="nofollow">https://dl.acm.org/doi/10.1145/234286.1057818 <a href="https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf" rel="nofollow">https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf
Steele wrote the Lambda Papers in 1975-1980, before CL existed. They contrast Scheme with MacLisp, and Steele then brought Scheme-style lexical scoping into CL.
CL marks itself as different from its dynamically scoped predecessors. <a href="https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html" rel="nofollow">https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html
> It's not common lisp.
It is, but you're correct, it's not core of CL, it's from ruricolist/serapeum - a widely known CL lib.
ltbarcly3 · · focus · HN ↗
How does that help me read Lisp code more easily? When I open a file with Lisp code in it, I just say to myself "this would be easier to read if they used serapeum instead of writing it in normal idiomatic Lisp" and then it's easier for me to read?
iLemming · · focus · HN ↗
ltbarcly3 · · focus · HN ↗
Stop threatening to prove me wrong and give it a shot. So far you have just said over and over "I shant deign to prove this wrong even though it is very easy to do so in so many way" then gave a bogus example and didn't address any of my points. You just keep saying "Nuh uh!"
iLemming · · focus · HN ↗
Opinions don't mean shit unless they are supported by evidence, and Lisp has plenty of it. It has survived subjectivity for almost 70 years, and it's still thriving. Good ideas don't need to prove anything; they just exist. If you still cannot see the reasons for why so many people still choose to use it, I'm sorry, that's just dumb and nearsighted. And you don't really have to listen to me - try to find some renowned CS academics or big-shot programmers publicly bashing Lisp - you won't find many.
ltbarcly3 · · focus · HN ↗
iLemming · · focus · HN ↗
Netflix uses it. Amazon uses it. Apple uses it. Walmart built their billing system in it. Cisco's entire cybersec stack is on it. Even NASA uses it.
Let's see, how has it been "dying"? Clojure, Clojurescript, Clojure-Dart, Coalton, Fennel, Janet, Jank, Jolt, LFE, Joker ... and these are relatively recent additions. The amount of Emacs Lisp on GitHub alone should be at least surprising - go check the GitHub lang stats, isn't it weird - a non-general-purpose PL, that has one and only one intent, is among the top languages, why? Check the r/emacs subreddit - there are daily, pretty much daily announcements of some new Emacs packages. Who the hell are these psychopaths? Don't they realize that Lisp is "dying"?
You don't know jack shit about whatever you're trying to talk about, and you call yourself "a hacker"? Honestly, it's pretty sad when someone can't find the time and patience to learn an instrument and then blame their own failure on the thing. Rather pathetic.
ltbarcly3 · · focus · HN ↗
Truly a success story.
iLemming · · focus · HN ↗
I bet you have no idea what Emacs is for, what it is capable of; you probably think it's "a text editor", yet in experienced hands it simply destroys all the other alternatives, easily. TextMate, Eclipse, Komodo, Aptana, Zend Studio, Dreamweaver, Brackets, Atom, Sublime Text - each of them at some point in time was more popular than Emacs, most of them slowly disappeared, Emacs is still here, stronger than ever. That is a success story.
I guess you have techno-myopia, and just can't see past your own bubble - some ideas are simply timeless: Lambda Calculus, Relational algebra and SQL, Vim modality, Regular expressions and finite automata, Homoiconicity, Unix Pipes, Curry-Howard, Immutability, Garbage Collection, etc.
None of that will ever be affected by the industry trends and will always be relevant. Nobody can kill Lisp because it's not a concrete implementation, it's an abstract idea. Clojure won't ever die, it will simply transform into another kind of Lisp. Just like it emerged as a Lisp, built on top of other ideas. Newton's laws no need to be "successful", they seek no recognition, it's not a popularity contest. They are still relevant, even after Einstein's discoveries.
What's your goal here? To prove something to me? Buddy, I'm far beyond redemption - I've seen way too much crap, and I learned how to collect good ideas and put them to good use. I suggest trying something like that. Some ideas are worth attention.
I don't know what the heck makes you so angry; I suppose it's your own inability to look into a given idea and, with candid curiosity, attempt to see what it is about. Your views are one-sided. You should at least acknowledge that I have seen both sides of that coin and maybe, just maybe, there's some truth in my tale, despite of me being biased (everyone, almost always is).