I&#x27;m not interested in differentiating between readability and comprehensability. If I want to work on some code I need to comprehend it. That starts &quot;in the small&quot; with the mechanical aspects of &quot;readability&quot;, if you will. Where to draw lines is not relevant. Every aspect to the process of comprehension is important. The &quot;small&quot; aspects are more important than you might think: Because they affect every line of code. Whereas there are fewer instances of the more global aspects to comprehension.<p>Like in a binary tree, where half of the elements are in the lowest level.<p>&gt; you&#x27;ve put parens around &quot;b c&quot; in the &quot;minus&quot; call<p>You have a point. One pair of Irritating Superfluous Parentheses less.<p><pre><code>    &gt; (sum (mul a (minus b c))
    &gt;      d)
</code></pre>
Even the consideration to sprinkle such a trivial expression over multiple lines hints at the superiority of a * (b-c) + d. It&#x27;s just the most straightforward thing to do. No far-fetched argument can change that.<p>I&#x27;d love to see eye-tracking data which show the tradeoffs between various syntaxes.<p>The regularity and the simplicty of sexps is of course good for computers, because these can barely associate. Because they can&#x27;t learn new tricks (they have fixed wiring). But humans have streamlined their languages (which also includes syntax; again, I&#x27;m not differentiating here) to their environments since forever.<p>Sexps are also good for abstraction and meta programming. But as we all know abstraction has a cost and there is no point in abstracting an arithmetic expression. And most code, for that matter.