> I have not yet encountered a fully satisfying explanation as to why Lisp is perceived as being less readable.

Difficulty is, by definition, relative to one's skill. You cannot so quickly discount the fact that 99% of programming is taught in Java/C style language syntax. If you've had lifelong exposure to Lisp, you might feel exactly the opposite. The author does a poor job of justifying why these pop-cognitive-psych theories should have more weight than prior exposure.

Personally, as someone with decades of exposure to both styles, I look at the factorial example and see everything I love about Lisp syntax - consistent, no magic keywords and syntax to memorize, it represents a tree just like my mental model of code, there's no way to fall through and forget an else, expressions instead of statements, no early returns ... literally everything about the Lisp example is more readable to me. YMMV.

every time I get to use lisp syntax I feel a sense of relaxation, as if the background stress of thinking about precedence and the meaning of all these magic sigils and control flow constructs just melts away and I can finally see clearly what's going on. my first professional programming language was lisp, and almost every single project in the 35 years afterwards was C style. but it still feels like home.

> Difficulty is, by definition, relative to one's skill

It's a factor and not the sole factor. Saying it's "by definition" is incorrect.

> The author does a poor job of justifying why these pop-cognitive-psych theories should have more weight than prior exposure.

There's no reason to believe either way, except one path has decades of evidence. Human behavior is not overcome by programmatic "elegance". The dismissive "pop" prefix is signaling bias.

> no magic keywords and syntax to memorize

ie no syntactic sugar. Pointless repetition is counter productive.

>a there's no [logical] way to fall through >b [no way to] forget an else, >c expressions instead of statements >d no early returns

b. The interpreter catches it. d. Pointless execution is counter productive.

> literally everything about the Lisp example is more readable to me

That's a single data point. Statistically it's worse, but you're practiced and apparently still physically able to quickly discern the nested count (or use an IDE). Yet another example of a position that is counter to existing studies. Heavy nesting is error prone, even when a program compiles (eg Monden et al., “Evaluating the Applicability of Reliability Prediction Models between Different Software,” ISSRE 2001)

Of course it's a single data point, stating my personal preference and the objective characteristics of the code that make it more readable, to me. That's what the article did too! But they tried to use their biases to establish a claim on objective truth. That's the difference - I'm not trying to make a generalizable scientific claim!

I'm trying to say that making such claims in the first place is invalid.

There is no language that is objectively more or less readable. Yes, I've read the studies. No, none of them come close to adequately addressing the confounding factor of prior exposure/education. A randomized controlled trial starting from childhood could establish such truths, but such an experiment has not been done. Until then, small-n studies that don't address this flaw in any way yet continue to make broad claims - "pop" science is perhaps not dismissive enough.

I tend to struggle with other people's indentation rules for code and other programming languages, like nobody liked my article that said you should carry indentation into embedded strings that represent other programming laguages like SQL

   result = sql.execute("""
      SELECT someColumn
      FROM thatTable
      WHERE anotherValue>55
        AND state='pending'
      ORDER BY createdDate
   """)

Ultimately the idea is that indentation should be influenced by semantics, the intention of the code, and not just the syntax. Of course that is against the "one way to indent" philosophy of Go, Biome, and such... But I might accept less than optimal indentation to put an end to tab wars once and for all.

I find indentation of Lisp always seems to fail at communicating in the semantics, much worse than other languages. Things like

   (if condition truePath falsePath)

are scrambled when your eye skips over something. If the Lisp community got over its respect for tradition perhaps they'd develop some kind of syntax highlighting or tooltips or something that would clarify this sort of structure.

About 90% of real language have subject-verb-object or subject-object-verb orders

https://en.wikipedia.org/wiki/Subject%E2%80%93object%E2%80%9...

verb-subject-object and verb-object-subject are more Lisp-like and represent 10% of languages including Standard Arabic, Finnish and Fillipino.

I like extreme parsimony, like I'd love to write stuff like

   format = lambda: `%1-%2`

but I think as complexity goes up depending on the meaningful order of elements breaks down in many ways and you need to give things meaningful names.

Isn't it extremely common for programming languages to put the verb first? They just write it as verb(...stuff...) instead of (verb ...stuff...).

Well, you see a lot of patterns. In OO there is the classic

   subject.verb(object)

In a case like

   add(left,right)

isn’t the return value the subject and left and right both objects? That way

   a = add(b,c)

Is really SVO.

That said, you can build data structures in Java with functions like

   Expression<Number> add(Expression<Number> left,Expression<Number> right)

and build something like S-expressions (not so nameless tuples) when you functions like the above, nested inside each other. You then can then write code to eval those expressions or write out Java code during a code generation phase —- it is fun on some level but if somebody else thought it combined the worst of Common Lisp and Java I woulsn’t blame them. Build a system like that and you will realize Expression<Expression<Number>> is a thing, you have to introduce a quote() operator, etc.

And that quoting is also part of the Lisp problem. You have to not only decode your code relative to distant parenthesis but you also need to know the quoting state of the code you’re looking at which could agin involved involuntary nesting. Burns up precious working memory, just as multi-line if requires cognitive effort because your eye is not guided by if/then/else. It’s another one of those languages like C++ that seduces smart people into burning up their IQ on trivia and you can’t get them to listen about it because they think they are smart.

One reason why our tools suck is that we are stuck representing programs as trees when they are really graphs.

For syntax highlighting try using a different colour for each level of indentation or parenthesis. I use prism-mode in emacs.

The parentheses are large glyphs that distract the eye, and do not stand out (to the untrained eye) as delimiters.

Consider:

  (defun split-line (line)
    (remove-if #'(lambda (word) (string= word ""))
               (split-sequence:split-sequence #\Space line)))

Now imagine if we had some "lower weight" glyph besides the paren.

  .defun split-line .line,
    .remove-if #'.lambda .word, .string= word "",,
               .split-sequence:split-sequence #\Space line,,,

Obviously a contrived example replacing () with ., but you can see how "heavy" the parens and how they can dominate what the eye sees.

With experience, the parens vanish. The parens being large and common take control of the conversation more than they should.

this actually gets at the real problem. Lisps are wordy as hell. like jesus

  (split-sequence:split-sequence #\Space line)

now imagine if that was

  (split-string " " line)

image if the whole function was

  (defun split (line)
    (remove [\(word) (= "" word)] [split-string " " line]))

or even

  (defun split (line)
    (remove "" [split-string " " line]))

*using [] in place of rainbow parens for clarity of sub arguments

I think with CLOS, you can go back to using single verbs for function names. However, this has a performance cost. Encoding the receiver type in the function names makes the call much easier to optimize.

What remains is field access. Curiously, first-edition K&R C actually required similar type-encoding in field names because field names were global:

https://usenet.trashworldnews.com/?thread=288637

Same for ML, which is roughly of the same age, except that it took much longer for ML-derived languages to lift this restriction.

On the other hand, every time I wrote down examples that I think should look really bad in prefix notation, like this one:

    p3.x := (p1.x + p2.x) / 2;

It is actually not so terrible with a sufficiently streamlined prefix syntax:

    (setf x p3 (/ (+ (. x p1) (. x p2)) 2))

But maybe there should be a mechanism that the reader transforms p1.x to (. x p1), in the same way that it transforms 's into (quote s). Then we get this:

    (setf x p3 (/ (+ p1.x p2.x 2)))

Or if there is a concept of a place:

    (set p3.x (/ (+ p1.x p2.x 2)))

But that probably needs static typing for an efficient implementation (or set needs to deconstruct its first argument during compilation).

  (split-sequence:split-sequence #\Space line)

Why would you do that? You could just use `uiop:split-string` and import the function symbol into your current namespace so you can call it as `split-string`.

  (split-string "a b c")

I mean ask OP, I don't know what's what in the Scheme rXrs or Common Lisp standard libraries.

Although my general stance remains, most lisp code bases I've seen are remarkably verbose which leads to a glazing over far more than the lack of distinct symbols or prefix notation

Lisp is why I started using emacs and its parens matching features.

I don't think the parens are the issue.

But when your function ends with ))))))))) -- that is the issue. Too much shit is being shoved into one method. But this is not the fault of lisp, it's the fault of the programmer who is wielding it.

That is frankly not a problem at all. People rarely bat an eye when your Python function ends by having eight simultaneous levels of dedent. People definitely don’t bat an eye when your HTML ends with </span></span></div></div></td></tr></table></section></body></html>. All you need is just good indentation, which is enforced in Python but optional in Lisps; then lazy programmers take shortcuts and don’t indent at all.

We can agree to disagree

OMG, the "improved" example is so cluttered and far far far less readable -- and even foreign -- to someone like me that has developed using lisp professionally for at least 10 years.

That's a crazy effect. For me, as someone who has a very minimal understanding of Lisp (apart from messing with it in Emacs for at most an hour), the improved version is much more readable.

Do you mean readable, as in it is easier for you to match "." to "," than ( to ), or is it just easier to look at without reading because there is less there.

The latter. Maybe it's different in Lisp, but whenever I read code, I rarely care about the exact order of operations, just which ones are actually being executed. In that regard, the improved version allowed me to comprehend the gist of what was happening much faster than the regular version did. For a few seconds, before even attempting to start comprehending the actual operations being executed, my eyes were stuck trying to comprehend the parentheses.

It's the same thing that makes reading Swift code hard if you never worked with it: lack of familiarity.

Exactly. Assembler looks like Gobbledegook. But if you have worked with it for a year it looks like a perfect and delicious dish.

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":

  user = find_user(user_id)
  require_admin(user)
  report = build_report(user)
  write_audit_log(user, report)
  receipt = send_report(report)
  record_delivery(receipt)

In Common Lisp, a direct translation adds a level of nesting for each binding:

  (let ((user (find-user user-id)))
    (require-admin user)
    (let ((report (build-report user)))
      (write-audit-log user report)
      (let ((receipt (send-report report)))
        (record-delivery receipt))))

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:

  '(:name "Ada" :age 37)

Association lists use a list of pairs:

  '((:name . "Ada") (:age . 37))

And LET uses two-element binding lists:

  (let ((name "Ada")
        (age 37))
    ...)

Lookup conventions differ as well:

  (getf plist key)
  (gethash key table)
  (assoc key alist)

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

There's so much crap here, I don't even want to waste my time to unpack.

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

     (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))
       

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.

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

https://www.lispworks.com/documentation/HyperSpec/Front/X_Ma... (no local there)

https://www.lispworks.com/documentation/HyperSpec/Front/X_Ma... (no def either)

> You are not familiar with the history.

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. https://dl.acm.org/doi/10.1145/234286.1057818 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. 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.

Lisp has had massive investment and almost 0 adoption, even in it's heydey. It's been dying for 50 years lol. It's crap.

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.

Truly a success story.

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

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

> For the record "Jtsummers" and "iLemming" do look quite a bit more alike than two random usernames!

Great. Arguing about "readability" with a dyslexic person. What could ever go wrong here?

> You are ignoring the part where you don't actually know Common Lisp and write nonsense code.

Read the usernames, "Jtsummers" and "iLemming" don't even look alike.

Personally, I find that a lot of LISP hackers put way too much logic into a single form or method rather than breaking it into smaller components that can be composed together. And I think that's often why we see frustration with LISP is that you'll have something that is indented really deep when it could be a much smaller function that's leveraging other functions. It's even worse in certain lisps like Clojure, where you'll see a lot of shorthand symbolic stuff, like for anonymous functions, or when you're using core.async, where you look at it and you think, is this brainfuck?

And the reason that LISP code tends to be reluctant to split things out into multiple forms with variable assignment IMO is because it introduces a new level of nesting. It's too much friction to go from

    (defn foo [] 
       (+ 1 2))

to

    (defn foo []
      (let [x 2]
         (+ 1 x)))

I wish that there were some kind of macro available in Clojure that would provide a local "def" kind of functionality that doesn't pollute the namespace and just creates a binding in the parent scope. So that you could do something like:

    (defn foo []
       (let! x 2) 
       (+ 1 x))

100%.

The better way is illustrated by this early example from SICP:

  (define (sqrt x)
    (define (good-enough? guess)
      (< (abs (- (square guess) x)) 0.001))
    (define (improve guess)
      (average guess (/ x guess)))
    (define (sqrt-iter guess)
      (if (good-enough? guess)
          guess
          (sqrt-iter (improve guess))))
    (sqrt-iter 1.0))

Observe that the problem of computing square roots breaks up naturally into a number of subproblems: how to tell whether a guess is good enough, how to improve a guess, and so on. Each of these tasks is accomplished by a separate procedure. The entire sqrt program can be viewed as a cluster of procedures (shown in Figure 1.2) that mirrors the decomposition of the problem into subproblems.

The importance of this decomposition strategy is not simply that one is dividing the program into parts. After all, we could take any large program and divide it into parts—the first ten lines, the next ten lines, the next ten lines, and so on. Rather, it is crucial that each procedure accomplishes an identifiable task that can be used as a module in defining other procedures.

etc.

1.1.8 Procedures as Black-Box Abstractions

https://sarabander.github.io/sicp/html/1_002e1.xhtml#g_t1_00...

I think it has to do more with infix vs. prefix notation - infix is more natural and easier to read.

When it comes to math, that's what people are familiar with so that is a factor. But function application is prefix as well for the majority of mainstream languages.

There's nothing "natural" about reading. We've not evolved as a species to have natural reading abilities. Of just about anything - be that cuneiform, hieroglyphs, katakana, math formulas or Sanskrit. Every person has to be taught how to read. A Mandarin-speaking person may argue that their writing system is "more natural" simply because it's one of the oldest and most widely used in history. Would you buy that argument?

Lisp isn't difficult to read, so I don't understand the question.

This feels like someone who doesn't know French asking "what makes French difficult to read?"

Exactly, it's just unfamiliar to most people.

I find Clojure (a Lisp) more readable than many other languages. It's the style I like for pseudocode. Because I used it a lot. It's familiar.

"Easy" is relative and doesn't mean anything without a subject. Easy for whom?

> Lisp isn't difficult to read

You'd be surprised how seemingly simple things can be hard for some. As an example, it's extraordinarily difficult for some HN users to read beyond the title and try to understand the reasoning behind it, so they instead settle for showcasing their intellectual prowess by answering the question outright as if that was the thesis. It's a very smart strategy, I must say.

> read beyond the title

Feels good to find a perfect opportunity to be witty and snarky, yeah? Well, allow me to murder this vibe of yours. Titles do exist for a reason. This article's title specifically, assumes too much. It's nearly click-baity. Imagine a title like "Why does the Holocaust feel like a hoax?", and then it goes into intricate detail to prove it isn't. Some people still get triggered by the title alone.

That went to Nazism real fast. But the thing is, most people don't think the Holocaust is a hoax (I think), whereas most people do think Lisp is difficult to read.

There have been lots of attempts to "improve" Lisp over the years (starting from the very earliest days) that assumed the primary thing holding it back was the syntax. All went nowhere, since that assumption is false. If you spend enough time to become familiar with the language (which you have to do with any new language) the syntax becomes a non-problem, and arguably something beneficial.

> That went to Nazism real fast.

Thank you. Perfectly proves my point. "Some people still get triggered by the title alone."

> most people do think Lisp is difficult to read

Correction. Most people unfamiliar with Lisp think that. I've been using Lisp for over a decade, I went to conferences, organized meetups, used Lisp for work and for personal projects, I met many experienced Lispers and I have mentored complete newbies. Not even once have I met someone in person who actively practiced writing and reading Lisp and ever complained about its readability.

What makes Ramayana difficult to read? Sanskrit - you need to learn darn language. What makes Quran difficult to read? Arabic - you need to learn darn language. What makes Lisp... the language, you need to learn the darn language. That's all you ever need to do. And you have to do it once, never twice, never repeatedly. Do it once in your life and that's it. It suddenly becomes not so difficult to read. Just learn the fucking language. Why the fuck complain about anything without first learning the darn thing?

My guy, most people are unfamiliar with Lisp

Most people don't know jack squat about first and second laws of thermodynamics. Yet I don't see articles of kind: "why physics is so difficult to grok" or shit like that. They don't complain about it, because everyone, even ten year olds understand - any shit feels difficult until you learn that shit.

.... Veritasium and a ton of other YouTubers made entire careers off of that. Steve Mould, the action lab... I mean there are so many

So what's your point? Physics is hard for those who don't know it? Butter is buttery, water makes things wet?

Any language is difficult at first. Nobody ever comes to any PL, opens random piece of code and goes like: "yup, I understand everything". It is called "code" for a reason, it's not "revelation", it takes some effort to grok it.

You should really follow the HN commenting guidelines, specifically #1, 7 and 11.

> follow the HN commenting guidelines, specifically #1, 7 and 11

This never occurred to me, you should really think about accompanying dang on his tireless job here, and maybe even get some dough along the way. I appreciate the insightful suggestion.

(The(.

People say we can ignore them but I find the difficult to ignore.

But this is not the only problem with lisp syntax. I found that reading Ruby or Python is simply, on average, so much more efficient.

I found scheme somewhat readable - see haxima game world, https://sourceforge.net/projects/nazghul/ it contains scheme files - but I would not want to write any game logic in it.

Unfamiliarity.

There is so much conjecture in this article -- take the difference between 'lisp formatting' and 'javascript formatting'. I use so-called 'javascript formatting' (a decided and embarrassing misnomer) routinely when I develop Clojure. This article exudes inexperience with Lisp.

You get used to it after a while and at some point the parenthesis 'disappear' and stop taking up mental cycles.

I often thought about this - at first I struggled a lot and wasted so much time trying to match parens, but after some time my brain adapted and then I actually liked the syntax, especially if your editor supports selecting forms or you use something like parinfer, which matches parens based on indentation.

Clojure has special syntax for collections of various types, so it's even easier to parse after you get used to it imo.

For me, the bigger challenge was wrapping my head around functional programming using immutable data structures, since that wasn't just syntax, it required me to 'unlearn' thinking in OO paradigm and adopting a new way of thinking about how the program works. You get used to that too after a while.

Similar to syntactically meaningful indentation, as with Python.

It's weird for a half hour, then it's second nature.

I love lisp and think it’s amazing. One of the things that commonly throws me off when I haven’t been writing it very much day to day is sometimes it’s unclear what’s going to be returned by a function.

An explicit return 0 is a lot more obvious than just having a 0.

Also, I’ll agree that a ‘ or a , in the wrong place is very easy to visually miss, then you can read a totally different meaning out of the code.

I'll repeat what other people here have been saying: I don't think Lisp is actually "hard" to read, in any objective sense.

It's "difficult" to read because it's different that other languages, but I think some of those differences actually improve readability once you understand the language. The forced use of parentheses everywhere guarantees that precedence is never ambiguous, for example.

I wouldn't say "never ambiguous" (at least for Scheme):

140 Assignment introduces a subtlety into step 1 of the evaluation rule. As shown in Exercise 3.8, the presence of assignment allows us to write expressions that will produce different values depending on the order in which the subexpressions in a combination are evaluated. Thus, to be precise, we should specify an evaluation order in step 1 (e.g., left to right or right to left). However, this order should always be considered to be an implementation detail, and one should never write programs that depend on some particular order. For instance, a sophisticated compiler might optimize a program by varying the order in which subexpressions are evaluated.

https://sarabander.github.io/sicp/html/3_002e2.xhtml#FOOT140

Hot take: it's the recursive referential grammar, which does not have an analog in human natural language.

Human languages have hard limits on the reference tracking they support, regardless of syntax (marking, positional grammar, etc.). Humans have to reason to unpack LISP (or deeply nested functions or delegation in other languages).

Lisp is more diffucult to read for most devs because most devs are used to C/Java -like synthax.

If most devs were used to Lisp, it would be the other way around.

It's a chicken and egg problem, at this point.

I think part of it is that English speakers say: “2 plus 2” not “plus 2 2”, so the infix notation matches our natural language and mental model.

Most languages use either subject-object-verb or subject-verb-object word orders, which together account for ~90% of world languages; verb-first word order languages only account for ~10% of world languages.

- add two and two

- compare apples to oranges

- use observational skills

(edit: formatting)

I don't think it's ONLY the parenthesis, it's also the lost opportunity to do meaningful things with indent that bothers me. For example: a missing end paren is often obvious where it should end to a human reader because the next definition starts at some set indent level (0 being the most obvious one). But we talk a different language to the compiler and to the human so the error message is far from where it would be useful.

Significant whitespace is actually a good thing™, even if you only use it to narrow compiler error messages. You can still have your parens but also get way better error messages if you just use the indent!

I have a suspicion that 99.999% of people who say that Lisp syntax is difficult to read haven't really tried to use it (outside of a random homework assignment in CS101).

The syntax is incredibly trivial, and needs very little initial instruction (except to tell newbs to stop trying to put the close-paren on a line by itself, like they are fresh out of a JavaScript boot camp and have no frame to conceive anything else, and that, really, the automatic indentation and the shapes should be at least as readable once you try to use it in real-world examples, and see how that works in practice).

> Since Lisp puts the function name after the opening parenthesis, there is more distance between the parentheses. This makes it less likely that the parentheses are close enough to be scanned as a single shape.

Or we can navel-gaze differently, and claim it's more a shape, because then it's a nicely rounded shape that contains the whole function application/call:

    (foo x y z)

    foo(x, y, z);

There is a small chance that you're doing the following in a Lisp or C, but you'd be doing something fancy that most people do not (like writing the internals for a pluggable framework or object system):

    (((f a) b ) c)    Pseudo-Lisp

    f(a)(b)(c)        Pseudo-C

If you were doing this, and you thought the particular code was hard to read, you could throw in a variable or two, for the intermediate function (or function pointer) values. Or use a combinator...

When you don't have this fancy function-that-produces-function-that-produces-function pattern, your list head will typically have the name of a function there, and then the syntax simple shape and indentation visually disambiguates.

In skimming the article, I did see something the article could've followed through on, for a good syntax criticism of many Lisps:

    f[a][b][c]    Pseudo-C, array access notation

Array-intensive Lisp code could use syntax/dialect extension for square brackets for this, if the Lisp doesn't already have comparable syntax:

    [m a b c]

In both references and setters; see my most recent mention of it: https://mastodon.online/@neilvandyke/117067069023420085

I think the biggest problem is that expressions are lists, but we build lists with quoting, AND unquoting (or quasiquoting). It takes some effort to look at an expression and be certain of what will be run. Are we displaying the instructions to erase the hard drive, or the output of erasing the hard drive.

Compare this with Prolog. I like to say "a term is just a term until it's a goal". Assuming we have an erase_hard_drive/1 predicate, I know it's safe to do

    write_term(erase_hard_drive([force,silent,noprompt]), [])

or

    EraseCommand = erase_hard_drive([force,silent,noprompt]).

What makes Lisp difficult to read is that almost everyone comes to a Lisp, with deeply ingrained writing skills suited for syntax-heavy, non-structurally-editable languages.

---

Now, to die on this hill.

Speaking as someone who desperately wants people to stop inventing syntax, I want to offer my "inversions" of the author's conclusions.

> prefix notation puts parentheses further apart

Prefix notation guarantees that I instantly know what the function / operator is and what the operands are. I don't see (or care) to literally read the parens. The parens are not the point.

And if we are doing this, let's compare real-world code shall we?

For example, how many syntax points (like = and ; and whatnot) do I not have in this code block (of my dotemacs) because regular prefix notation means I can set any number of global variables in one single declaration? https://github.com/adityaathalye/dotemacs/blob/3ce80d8336ae8...

As a bonus, because of the prefix guarantee, when teaching someone a Lisp, I spend almost no time teaching the semantic meaning of syntax rules. All I have to do is show how prefix notation works, and drill that a few times with hand-coding exercises.

> formatting practices do not help to track parentheses

Auto-formatters---once again, because of prefix notation---can lay out code in very regular patterns and shapes. Auto-formatting further obviates the visual / aesthetic relevance of parens.

Not to mention smartparens and structural editing and other basic niceties of Lisp text editors.

> prefix notation results in more left-nesting

Perhaps. The value for me is that it results in more regular code, because, once again, standard prefix notation, and once again, standard auto-formatting. Nobody reads closing parens, or opening parens, or whatever other parens... we let our text editor take care of that stuff for us.

> Lisps lacks or discourages features that align the evaluation and reading order

This depends on whether the Lisp in question is imperative, procedural, or functional. It has nothing to do with S-expressions...

Essentially, the author makes the usual category error of conflating "Lisp" with "s-expression".

May I suggest associating "Lisp" with "Metaprogramming" as the better evil? Die-hard Lisp-2 nerds will balk, but I say any language with an ability to symbolically manipulate itself as its own data is a Lisp. For example, Julia is a kickass Lisp because it enshrined meta-programming as a first-class language design concern. Ditto Elixir. I'm happy thinking of those as M-Expression Lisp-likes.

And as a matter of personal taste, having been around lisp nerds, nobody who actively writes s-expression languages---even as hobbyists---reads parens. They/we see shapes and we manipulate our code like tetris, without even having to think about 'em parens, and soon enough, nor about the keyboard shortcuts.

Whether Emacs, or Vim, or VSCode, or IntelliJ or, whatever Lisp-aware editor, we simply slurp and barf and splice and unsplice and convolute-sexp, all of which I do as a normal part of Lisping https://emacsrocks.com/e14.html ... And this stuff is so readily possible because of the regularity of prefix-notation s-expr syntax.

(edit: add code example)

I honestly never understood this premise of Lisp being "difficult", "demanding", "complicated", "taxing" or "annoying" to read. Over the course of my career I've had to learn over a dozen different PLs. Every single one of them was "hard to read", until it wasn't. Every single one of them required some initial effort, and not a single one of them was like "yup, I clearly understand everything, don't even need to read the docs..." And honestly, I'm not even a very talented programmer. I'm pretty average.

What's interesting is that at the point when Clojure finally started feeling more intuitive and I was able to quickly scan the code snippets and understand the flow, it almost wondrously opened the gates for just about any Lisp. I can easily switch between Lisp dialects, as a matter of fact I can do it multiple times a day and the overhead is so tiny, it feels like I'm dealing with the same language, just on a different platform. It's by far the easiest language to deal with, be that Clojure, Clojurescript, ClojureDart, Fennel, Elisp, CL, Jank, Jolt, etc.

I think most programmers simply don't do that. They don't switch between different platforms (and thus languages) very often, they pick one or two, get proficient with them and build some loyalty or whatever, the language almost becomes their identity (at least at that point in their lives, until they find a new one).

And then the problem with Lisp dialects is that they are pretty niche - they are not so widely used in the industry, therefore the incentive to specifically learn Lisp is very moderate at best. But people hear stuff like "how expressive and powerful...", "Emacs has no competition", yada-yada and they'd try to spend a weekend to see what it is about, then look at the unfamiliar syntax and go like: "hmm, I don't know..." They try to learn kung fu but skip all "Mr. Miyagi's bullcrap". Alas, it just doesn't work that way.

For me, it was absolutely worth it. I think learning Clojure saved my career. At the time I was so overwhelmed with complexity in the apps I was trying to build and maintain. I started having an existential crisis - I thought about leaving the field for good and starting something else. Turns out, I wasn't a complete failure, I wasn't stupid, and I didn't lack incentive. I just needed a different perspective. And that "weirdness" and "uniqueness" of Lisp was that inflection point that I desperately needed in my life. Guess what? Becoming a Lisper helped me understand other languages much better.

I think I found a lifehack - want to become a polyglot programmer without wasting ten years of your life? Grok Lisp. It will do.

Some of the Lisp features that people don't like are built into the language. If you don't like them, there are other languages you can use instead. If you're already using a language you prefer, why are you complaining about Lisp?

Some features are dialect dependent. If you like the idea of a Lisp, but specifically don't like e.g. Common Lisp, Scheme and Clojure are alternatives. If you don't like these either, nothing is stopping you from writing your own Lisp and using that instead. I have. Lisp is one of the easiest languages to implement and there are two excellent books explaining how to do just that.

And if your problem is just with formatting or getting the parentheses right, you're probably using the wrong editor. You won't have these problems with EMACS.

You think Lisp is hard to read? Then try J! And still people use it and are very successful. It is not always the ease of readability but the power of the syntax that makes a good programming language.

https://www.jsoftware.com/

p.s. R is Lisp with a nice syntax. Much more readable and still very powerful.

just my 2 ct

R is already a Lisp dialect disguised in algebraic syntax. Here is the first example in R:

  factorial_recursive <- function(n) {
    if (n == 1) {
      return(n)
    } else {
      return(n * factorial_recursive(n - 1))
    }
  }

https://cran.r-project.org/web/packages/codetools/codetools....

then gives:

  (<- factorial_recursive (function as.pairlist(alist(n = )) 
    ("{" (if (== n 1) 
      ("{" (return n)) 
      ("{" (return (* n (factorial_recursive (- n 1))))))
    ) NULL)
  )

Somewhat related: Readable Lisp S-expressions Project

https://sourceforge.net/p/readable/wiki/Problem/

(I learned Lisp in the 90's and enjoyed it, but I still find it difficult to read.)

It is too uniform, which makes it hard.

Everything is a list or an atom. There's no variety and it doesn't take advantage of pre-existing knowledge.

For example, in most curly braced languages a block is very different from an argument list, not so in Lisp.

There's not many visual cues of what function something does, anything can be anything.

Even math expressions are weird (because there aren't any), you cannot leverage years of training reading simple math notation to make sense of stuff.

There is an answer to this so fundamental and obvious that I am shocked people have been blind to it for ... decades? ... a quarter century? ... a half century? ... longer??

I expect this perception to turn on its head.