The first example actually has more bracket pairs (7) for Javascript than for Lisp (6). Rainbow bracket modes for editors can help when bracket matching is an issue.

This example which suggests counting parens is also solved by rainbow brackets, and/or editor tooling like paredit-mode that won't even let you type mismatched brackets:

(f (g (h (i (j)))))

And in most modern Lisps, one might use a thread/pipeline macro instead:

(-> (j) i h g f)

With mixed nesting, Lisp programmers often use newlines to improve clarity:

(aap noot ((mies wim) zus) (jet teun vuur))

becomes

(aap noot
     ((mies wim) zus)
     (jet teun vuur))

A later example in the post does that:

(sum
  (filter
    (split (read (open "input.txt")
                 ",")
    (lambda (it) (> it 0)))

Which makes one of the errors it contains clear: "," should be an argument to split, but here it is an argument to read. It is aligned with the start of the first argument to read, so that's very visible. There are also two levels of unclosed parens. Pasting it into an editor made that clear instantly.

This version is correct:

(sum
 (filter
  (split (read (open "input.txt"))
         ","))
  (lambda (it) (> it 0)))

But I'd probably write this with a thread macro:

(-> (open "input.txt")
    read
    (split ",")
    (filter (lambda (it) (> it 0))))

It's possible to write unreadable Lisp, but people who are good at Lisp don't. This is true of most languages.

Lisp.

I agree very much.

When I started developing in Clojure, I came across a lot of Clojure code that simply seems to be formatted/aligned "wrongly", which was just my intuitive understanding of what the article names more accurately.

It felt to me like everything was too cramped, not grouped properly.

Luckily, it was super easy to fix for me in my code, just do some different alignment and line breaks and readability increased a lot. However, it now doesn't look like "standard Clojure" which might be its own problem in collaboration, I don't know.

I wanted to learn lisp, but the default formatting is just terrible. If it had a different formatting and supported infix notation, it would be readable to me.

JS written by different people became easier to read since Prettier appeared. When others' code is formatted just like your code, it saves effort. Idk if Scheme or other Lisps have standard formatters now; there wasn't one for Guile when I learned it.

I get because I was like that when I first experienced lisp but I like lisp now.

I found it pretty messy when I was going through the land of lisp book but lisp is pretty flexible and you can make it readable.

When I was converting my 3d game engine to hare lang I missing the flexibility of lisp.

I'm still convince that polish notation was the biggest mistakes of Lisp. At some point, the guy who create Lisp language decide to get rid of 2 centuries of mathematic convention just because of a technical limitation that last for maybe 2 decades.

Oh, and no one to talked about (1- x) ?

the leading question does. :3

The speech impediment part most likely.

The URL slug is 👌

I also always find this frustrating, when people say Python is easy to read, because it looks like plain English, since it doesn't have as many symbols.

We didn't put those symbols in out of boredom. They help to visualize concepts that the English language does not have. They're there to improve readability.

Disclaimer: I stopped reading at 3/4 of the article and started scanning because it looks like lack of familiarity looking for a scientific explanation. Then scanned parts again for a lengthy response to clear my thoughts. That may be wrong and I've heard the complaints but my experience is different. Much of why it doesn't resonate is looking at it from a different perspective by different experience.

I mostly write javascript and some lisp and a smaller portion of python, ruby and others. The lisp parens are substantially easier for me to scan than the Java syntax for everything except nested function calls which start with many open parens. Common Lisp doesn't do that often so it is new to me like the Java syntax was new to me back in the day. Good as an abstraction if that's what you get to work with.

I would love for my experience to be different because then I'd enjoy Java.more(with,all){ the(); weird(); return symbols();}. But I do not. Lisp groups things starting with an opening paren up to the closing paren. No scanning for the type of grouping like (, {, or [. Simple and consistent. Indentation is done automatically based on the meaning of the code and parens do the logical grouping (it works just like it works in sentences (but deeply nested parens are weird (like deeply nested routines (and we should limit that)))). There are places where it's nice to escape from parens and Common Lisp allows for that so you can create a mini language without the parens (other lisps allow for that too). It is not created often but there are cases where that helps a lot.

Both java and lisp wordings have their pros and cons. Deeply nested function calls are often solved with a macro to flatten that in Lisp. You don't have that syntax flexibility as easy in Java but you can make other abstractions to lower the pain. In the end it's finding the right vocabulary and structure to explain the problem and the solution. Each language has its own tools for that. Lisp has less familiar tools but you can do more with them. Once you know it's hard to settle for less but if you don't it's hard to see what you're getting bound by. In the same way lispers don't always see the many libraries available in python, pythonistas don't see the limitations the language itself imposes on them.

The article, to me, thus reads as the statement "parens feel hard to read to me" searching for a reason other than "I have not seen it as often". I have seen far more C-like syntax than Lisp but I've seen a good share of lisp too. Structure is more apparant to me in Lisp like languages. It is cleaner for words to be split by spaces than,for,them,to,be,split,by,commas in an argument list.

In my opinion, Lisps are hard to read because they use eq and eql and equal instead of === and ==; and setq and setf and let instead of =; and car and cdr instead of first and rest. Historic wording. Also in elisp I find it hard to find the right function name. Yet in our configuration DSL most non lispers choose the Lisp syntax over JSON but they only liked it after the JSON syntax became an option too. Until then they wanted JSON.

I have noticed a difference in reasoning about code. A lot of Lisp code reads like an outline where you zoom in to the relevant spot. A lot of Java and Javascript reads like a series of commands you execute in your head sequentially. The languages lend themselves to such code even though they support both ways of writing. Perhaps that difference was not experienced by the author?

This comment is really just another person's experience but it's a different experience that what's projected in the article.

To come to the conclusions from the article:

• Claim: "prefix notation puts parentheses further apart"
• Reply: The parens fill space and the whitespace shows what belongs together, it is the closest consistent grouping and allows arguments to be read by space separated words rather than hard to read commas or by newlines if that helps scanning the code. In case the arguments (or a subset of them) warrant specific grouping, lisps offers support for that in a mkre integrated manner than Java does.
• Claim: "formatting practices do not help to track parentheses"
• Reply: use a formatter, it does that. Lisp code reads like a nested structure you walk rather than a piece of code you mentally execute line by line. We don't format whitespace at the start of the line in Java either, right?
• Claim: prefix notation results in more left-nesting
• Reply: use a macro, currying, or any other macro structure when it helps. Turn the language into whatever you need to express the solution. If I have too many parens I rewrite the code just like you'd do in amy other language. Executing Food.buy().bake().serve().eat() is a cool Java DSL and reads nicer when written in lisp as (-> Food buy bake serve eat) anyways so why write (eat (serve (bake (buy food)))) if your focus is not eat. Though if it is eat then do write that. Or perhaps write it in the other direction with compose. So many options if that's the sort of code to write.
• Claim: Lisps lacks or discourages features that align the evaluation and reading order
• Reply: I agree and it's good. Other programming languages focus on the execution of commands following one another. Lisp encourages a functional programming style where the structure makes meaning easier to navigate through the code. Both are possible in a variety of languages. That's a choice though, not a problem. It is trivial to use abstractions that neatly express such an order even when the code around it is not made for it (with-food-plan (buy) (bake :lightly) (serve :hot) (eat)) and the function calls will be nicely indented on newlines by your editor if that's the best use of the space.

On the advice:

• advice: "order notation such that related tokens (e.g., delimiters) are as close as possible"
• reply: Lisp has that and more than other languages. You can make up your own syntax when the problem warrants it. For example the loop DSL for looping over lists. It's just not always the best to read.
• advice: "use the shape of code to communicate grouping"
• reply: yes. The opening paren starts the group, the closing ends the group. The meaning of a group is fluid but consistent. Use newlines and auto-formatting for easy vertical scanning of lisp code.
• advice: use associativity to prevent nesting delimiters
• reply: not sure but I think the answer are DSLs or macros when things get too bad. But sure, readable code is nice. Context switches are hard.
• advice: design syntax and semantics to align reading with evaluation order
• reply: I disagree here but it's the difference of functional versus procedural thinking. Code needs to explain itself. The order of evaluation is what a computer needs, I need an order of understanding. If I can have my way I'll optimize the code to have the main structure and reasoning up front and the details and exceptions at the bottom. I don't care about negative numbers being a special case early on through an early return, I want the know what the general algorthm is first. Some disagree. Evaluation order is super important for computers but I don't care how my SQL query is executed, I care to understand it and for it to be fast enough. Otherwise I'd use a different technogy.

Not mentioned in these are symbols such as a < b versus (< a b). I like the former better. But a < b < c has more room for interoretation than (< a b c) for me. An infix macro can easily solve the problem to read as (. a < b) and we can go further too.

So, much of this is probably written with the best intentions and a real experience. I can see it being true for their point of view with their history. This is also just a quick thought and response tk put things in persoective for me. A response through a different lens with a different experience.