Comment by adityaathalye
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)