For me S-expressions feel like the most natural way to program because they compose naturally with zero ambiguity. Infix notation might be slightly clearer for simple expressions but it doesn't compose: As soon as you try to compose infix notation you have to add parens, depend on unstated precedence rules, or both. Lisp's philosophy is to just use parens everywhere, make everything composable, and have no precedence rules.

That said, I would hate to write Lisp code with Notepad. Fortunately nobody does this. In conjunction with a paren-matching, auto-indenting programmer's editor (which is roughly all of them these days), S-expressions are easy. A good editor is vital not just for writing Lisp programs but also for reading them.

I will not claim parentheses are mandatory. I find Haskell just as simple, unambiguous, and composable without (many) parens but that's only because it has automatic currying, and that takes a bit of practice to wrap one's head around.

IMHO, if you need an editor with paren-matching and auto-indenting (and maybe even syntax highlighting) just to make working with your language tolerable, that's a possible design flaw in the language.

I know it's heresy in a Lisp thread to claim that it's possible for a language to have too little syntax, but I can write Javascript, C and C++ just fine in Notepad or Sublime Text if I want.

My one counter argument for 1 and 2 is that with infix, I'm forever trying to remember precedence rules and in my own code, just end up wrapping everything in parentheses anyway, to be sure. In lisp, the ordering is always explicit.

For 3, that's one reason why I like Clojure's syntax: it has just enough extra syntax to break up the code and provide visual cues, at least for me.

Re 4, sure, you can even enable macros without homoiconicity, but with s-expressions, I find it to be mentally much simpler because I can just write a template and fill in the gaps and its natural since my code is in that form already. Overall, though, in all but a few cases, I think macros should be avoided in favour of pure data structures and functions, when possible.

You're right. Lisp syntax makes the totally wrong tradeoff of being slightly easier to parse for the machine, and much harder for the human. An eloquent name for it is that Lisp fails the squint test https://www.teamten.com/lawrence/writings/the_language_squin...

I have to say applying the squint test to language design seems immensely confused to me.

The syntactic structure of both "code" snippets seems equally clear (or maybe "uncertain in the same ways") to me, though my understanding might be a bit off if the author has biased the comparison by following generally accepted use of whitespace with one language and not the other.

This looks like another instance of slapping a pseudo-scientific veneer on top of conclusions driven more by untrained gut feeling in order to pretend one's subjective impressions are firmly grounded in objective reality. It's like the phrenology of programming languages.

I love s expressions, i can now manipulate my code semantically thanks to paredit & co. Learning vim is the first step to being able to properly manipulate code. Paredit is the next and last step ;)