Lisp uses the same number of parens as most languages per call – the only thing that's different is whether the paren goes before or after the first part of the call.
(print "hello")
vs
print("hello")
So to the extent Lisp is paren-heavy, it's more a stylistic thing. Lisp programmers tend to chain up calls more.
Lisp only has infix macros so that we can say "we have that".
Nobody in their right mind uses this stuff in production code.
It just overcomes objections. "Oh, if I start using Lisp, there is be a way to use infix, should I really need it".
Ten years and six Lisp project later, you still haven't used the infix stuff; the situation never comes.
> Nobody in their right mind uses this stuff in production code.
You sure about that? I thought the lispy approach was generally pragmatic - you use what you deem handy for your application. It this weren't the case, there would be little need for macros in the first place. I can very well imagine, say, a scientific or engineering application that would share a common infix parser for both user-provided expressions (in the UI, to be more friendly to non-lispers) and heavy math lifting in the source code.
But! Perfect splitting across lines according to a formatting algorithm which is simple, consistent, and incrementally applicable:
1.
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c))))
(* 2 a))
2.
(/ (+ (- b)
(sqrt (- (* b b) (* 4 a c))))
(* 2 a))
3.
(/ (+ (- b)
(sqrt (- (* b b)
(* 4 a c))))
(* 2 a))
4.
(/ (+ (- b)
(sqrt (- (* b
b)
(* 4
a
c))))
(* 2
a))
Now you have a sideways tree, revealing the structure of the expression, where it is immediately apparent what the operands are of the / and the + and so on.
Infix turns into a mess breakfast when it's too long for one line.
For this particular expression, I'd probably go with variant (3) in production code. Compared to the beauty of (3), the original one-liner is basically a strawman. In terms of clarity of structure, it trumps the infix also.
This is actually a very important point that is overlooked by Lisp noobs. In real Lisp code, expressions are not written all out in one line, whereby the human reader must mentally match the parentheses. Even numeric expressions that might be one-liners in Fortran or C, are split across several lines to make at least the major constituents clear in relation to the major operator.
Yes, and the first line's use case depends on the language built-in operator precedence rules to reduce the number of parens.
If you are using math formulas as an example of minimal paren usage, go with APL and have even fewer since all operators are equal precedence and associate to the right.
If you really wanted to write the quadratic formula (or math formulas in general) you could use APL and use even fewer.
> Lisp uses the same number of parens as most languages per call
Furthermore, Lisp uses zero parentheses for grouping in order to override precedence. These parentheses don't exist in Lisp.
In print(2/(2+4)), we actually have two kinds of parentheses, because two different grammar rules use the same token.
C has even more parentheses. The parentheses in for (;;) are not the same as those in 2/(2+4) which are not the same as those in (double) p, which are not the same as those in p(42).
Lisp has parentheses that do one darn thing in the read syntax---at least when they are not literal as in "(" or #\(.
