Especially that alternating pairs business.
Having to know what is a macro and what is not affects understanding how arguments are evaluated, and basically everything is an argument differentiated only by position.
I've head one should read a lisp function not from the top town or outside in, but rather from the most indented part first, and then work your way up and out to discover the definitions.
The whole point of macros is that they are written in the same syntax as everything else (because of homoiconicity you can operate on your code as native data), you don't need to know what is a macro and what is not for 90% of the code you write. There are very little cases in Lisp languages in general where the difference between a macro and a function are evident, and in Clojure even less (compared to another dialect like, let's say, Common Lisp).
There are some times where that might be useful, but that's why we have a repl and macroexpand.
"that macro function is called and is passed the unevaluated operand forms. The return value of the macro is then evaluated in its place.
If the operator is not a special form or macro, the call is considered a function call. Both the operator and the operands (if any) are evaluated, from left to right." - http://clojure.org/evaluation
There are many macros and special forms in clojure where you have to understand that the arguments are not evaluated first - and if you try to reason about what happens as if they were eagerly evaluated you get the wrong answer or an error
That's why the pipeline operator (->>) is common. Then you just read it from up to down.
https://github.com/stuarthalloway/programming-clojure/blob/m...
https://github.com/tcltk/tcl/blob/master/generic/tclCompile....
Grabbed at random. I think the larger indentation and fewer parens do make a difference when you squint at things.
Of course, I also think as a professional programmer, if something does the job, get over it and get on with it. I use Erlang myself, which also gets lots of syntax complaints.
Just squinting at the code to see the shape of it rather than worrying about the contents, the C blocks look more distinct, to me.
I don't feel that there's anything particularly magical with the paren being on the left hand side of the verb that automatically makes it less readable than when it is on the right hand side of the verb.