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:
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.
Thanks for this, I was half going to respond with a glib “skill issue” in response to the article
I worked with Scheme on a project about a decade ago now, and the only code in the project that wasn’t particularly readable was the code written by someone who didn’t attempt to learn conventions and appropriate tooling before contributing.
I was tempted, but nobody learns anything from that.
I have the impression the author of the article has dabbled with Lisp but hasn’t actually set up a reasonable development environment and written something non-trivial. That’s not a great position from which to write critiques of a language.
Threading macros, rainbow parens, and paredit style auto closing parens make lisps syntaxes pretty easy to read and manage. I think declarative style languages like ML and Haskell took me longer to get familiar with than lisp style syntax, but that’s probably just because I learned procedural languages first. And I think lisps tend to be more syntactically dense than say Python or C or other languages most people start with.
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:
And in most modern Lisps, one might use a thread/pipeline macro instead:
With mixed nesting, Lisp programmers often use newlines to improve clarity:
becomes
A later example in the post does that:
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:
But I’d probably write this with a thread macro:
It’s possible to write unreadable Lisp, but people who are good at Lisp don’t. This is true of most languages.
Thanks for this, I was half going to respond with a glib “skill issue” in response to the article
I worked with Scheme on a project about a decade ago now, and the only code in the project that wasn’t particularly readable was the code written by someone who didn’t attempt to learn conventions and appropriate tooling before contributing.
I was tempted, but nobody learns anything from that.
I have the impression the author of the article has dabbled with Lisp but hasn’t actually set up a reasonable development environment and written something non-trivial. That’s not a great position from which to write critiques of a language.
Threading macros, rainbow parens, and paredit style auto closing parens make lisps syntaxes pretty easy to read and manage. I think declarative style languages like ML and Haskell took me longer to get familiar with than lisp style syntax, but that’s probably just because I learned procedural languages first. And I think lisps tend to be more syntactically dense than say Python or C or other languages most people start with.