Not going to comment on the “objectively” part of this discussion. But having come to S-exps late in life, I would say they definitely are “simpler” over the whole problem domain of programming computers. Programming has many examples of syntax and constructs that definitely are simpler for grade school level programs, but which make your life a living hell of complexity if you rely on them for building real-world software.

I think you're describing the difference between being "simple" (objective, absolute) and being "easy" (subjective, relative).

Of course, I'm paraphrasing this classic: https://www.youtube.com/watch?v=SxdOUGdseq4

Infix works for binary operators at the cost of requiring operator precedence. Hence the parens you wrote.

Prefix works for variadic operators like the +, - and / in your example, without operator precedence rules to get wrong. And if one can't reliably remember how those rules differ between languages so people wrap everything in parens anyway, what exactly did you gain from rejecting prefix?

> "objectively simpler" is just false. You might prefer it, but that doesn't mean it is simpler.

I meant in terms of the complexity of the code needed to parse them. In that respect they are clearly objectively simpler. The entire field of parser theory exists entirely because of non-sexpr syntaxes. Parsing sexprs is an elementary exercise.

When I compare this √(3x3+4x4) expression mixing infix or prefix operators with specific precedences and orders of evaluation to this one (√ (+ (x 3 3) (x 4 4))) coming with a unique and systematic syntax (operator values), which is nothing but a short notation for « take the square root of the sum of the product of 3 and 3 and the product of 4 and 4 » and which is easy to evaluate from inside out, in 3 steps (√ (+ 9 16)), then (√ 25) and finally in 5, when I compare them I understand why so many peaple don't like maths. You believe that 1+2x3+4 is easy to understand but it's not, too many things are behind the cap, beginning with precedence. There is nothing under the cap with (+ 1 (x 2 3) 4), when you know that (operator values) says replace values by what is returned by the operator and when you know that evaluation is always done from inside out. Let alone "special expressions" - like lambdas - but it's another thing.

> When I compare this √(3x3+4x4) expression mixing infix or prefix operators with specific precedences and orders of evaluation

Ignoring the latter part and only responding to the first: Root is infix, the left side is just implied 2 here.

I definitely find the former much easier to visually parse than the latter. I liberally unneeded parenthesis to emphasize parts of an operation which might depend too much on operator precedence, but humans are not great at keeping track of many nested parentheses.

These kinds of expressions tend to end with a cluster of parentheses, and it becomes hard to identify the beginning and end of each one, and making sure they're being closed at the right scope. Before someone comments "the editor will keep track of them for you", I want to answer that needing a tool to keep track of nested parenthesis might be a sign that such notation needs improvement.