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.

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

  (split-string " " line)

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

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

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

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

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

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

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

  (split-string "a b c")

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

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

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