> This provides visual cues about scope and intention without first reading each token.
There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this.
The C function definition doesn't have an operator which would help me to identify what it actually is.
float square ( float x )
{
float p ;
p = x * x ;
return ( p ) ;
}
Where in Lisp we have this operator based prefix syntax:
(defun square (x)
(* x x))
Oh, DEFUN, short for DEFine FUNction, it's a global definition and it defines a global function.
Or with types/classes:
(defmethod square ((x float))
(the float (* x x)))
Oh, DEFMETHOD, DEFine METHOD, so it's a global definition of a method (kind of a function).
The names and lists may not tell you much, but to a Lisp programmer it signals the operation and the structure of the code, based on typical code patterns.
Once we learned basic Lisp syntax this is the usual pattern for definitions:
<definition operator> <name of the thing to be defined> <parameters>
<body of definition>
Most definitions in Lisp follow that pattern. Function definitions extend/refine this:
<define function> <name of function> <parameter list>
<declarations>
<documentation>
<body of definition>
Code then has a layout which is always similar - since the layout is hardwired/ supported in editors and Lisp itself (via the pretty printer, which prints code to the terminal according to layout rules).
> block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent
These are also hardwired in something like Common Lisp. But the general language is differently designed. Common Lisp has relatively few built-in basic syntactic forms (around 30) and the other syntax is implemented as macros.
> It's great if you are the lone reader: you can customize it to fit your head
Over the decades of Lisp usage a bunch of conventions and some language support for common syntactic patterns have emerged. It is considered good style to follow those patterns.
> But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop.
That's the same problem everywhere: the new control structure implemented as a Lisp macro is the new control structure in any other language implemented by a bunch of different tools (macros, preprocessor macros, embedded languages, external languages, a web of classes/methods, a C++ template, ...).
If you add a new abstraction, there is always a price to pay. In Lisp the new language abstraction often gets implemented as a new macro and may hide the the implementation behind a more convenient form.
