| HN Mirror

> 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.