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.

I will never not post this picture on this subject. Skimmed through the article, seems well written and will read it later.

Edit: did read it through, and don’t necessarily agree. I don’t think about any of this when writing lisp code. Emacs deals with my parens, as does paredit and structural editing. This discussion ignores the things that makes lisp work: s-expressions. By changing this main feature, one destroys lisps best feature.

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.

It's honestly more familiarity than anything else, and it's mostly that Polish notation isn't how people learn to read math in school. If Polish notation was how math was notated then lisp would be the easy one to pick up. Similar to how natural languages have the parts of speech in different places in sentences.

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

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.