Alan Kay on Lisp

Thanks!

It's probably more literally true than he intended. And 7 isn't really a cliche; it's not an opinion but a thoroughly proven, universal limitation of human working memory.

Before the advent of cheap writing instruments, and especially cheap printing, we used poetry to almost effortlessly recall and communicate large working sets of data, privately or in discourse. With poetry and similar mnemonic devices people memorized volumes of information. A student or scholar in ancient Greece would have literally memorized all the classics. Someone like Cicero would write a speech of 5,000 to 10,000 words and then, a few days later, deliver it nearly verbatim from memory. The dominate form of mass communication was through open speeches, and this is why most of the great speeches came from the ancient world. But it was limited; recalling and sharing was easy, but memorizing was still laborious, notwithstanding the fact that ancient scholars' memorization faculties seem like super powers to modern humans.

With the advent of cheap writing and printing, we were able to archive, recall, and disseminate magnitudes more information at a more rapid pace. And while slower to recall, speed of creation and dissemination, and sheer volume more than made up for that limitation. Moreover, mass communication proved far more efficient in written form.

Today computers are killing writing just as writing killed poetry. But it's not really computers, per se. With writing it was the system of creating and using written works (alphabets, printing presses, libraries) that actually realized the efficiency gain. In Alan Kay's view, Lisp is what made the promise of computers realizable, capable of supplanting the dominant form of "thinking" and of opening up new frontiers. Computers are like papyrus; it's learning how to use them that matters, and Lisp was that great leap. It's one thing to laboriously write a program using machine code; it's something else entirely to do this using an elegant, higher-order programming language. Indeed, once you use that higher-order language you can't go back; it changes how you think about programming, including how you structure programs written in machine code. Like with poetry and writing the utilitarian leap in productivity is forgotten because it becomes so effortless and seemingly obvious; instead all you see are the limitations and faults.

Sure, I meant static types + Hindley-Milner type inference, leading to a "type system that I like and feel comfortable with" (per your link), i.e. a stronger type system.

Most of the examples I gave above are core syntax forms. They are defined in the language grammar and are not function calls or macros. See the Racket language reference [0]:

> A core syntactic form[] is parsed as described for each form in Syntactic Forms. Parsing a core syntactic form typically involves recursive parsing of sub-forms, and may introduce bindings that determine the parsing of sub-forms.

  top-level-form = general-top-level-form
   	 | (#%expression expr)
   	 | (module id module-path
             (#%plain-module-begin module-level-form ...))
   	 | (begin top-level-form ...)
   	 | (begin-for-syntax top-level-form ...)
  
 general-top-level-form = expr
   	 | (define-values (id ...) expr)
   	 | (define-syntaxes (id ...) expr)
   	 | (#%require raw-require-spec ...)
  
 expr =  id
   	 | (#%plain-lambda formals expr ...+)
   	 | (case-lambda (formals expr ...+) ...)
   	 | (if expr expr expr)
   	 | (begin expr ...+)
   	 | (begin0 expr expr ...)
   	 | (let-values ([(id ...) expr] ...)
             expr ...+)
   	 | (letrec-values ([(id ...) expr] ...)
             expr ...+)
   	 | (set! id expr)
   	 | (quote datum)
   	 | (quote-syntax datum)
   	 | (quote-syntax datum #:local)
   	 | (with-continuation-mark expr expr expr)
   	 | (#%plain-app expr ...+)
   	 | (#%top . id)
   	 | (#%variable-reference id)
   	 | (#%variable-reference (#%top . id))
   	 | (#%variable-reference)

See section 1.2.3.2 which specifies the expansion steps. Note that the expansion model differentiates between handling transformers aka macros and core syntax forms.

To be fair, it seems that Scheme (R5RS) considers some of these forms to be "derived expression types" and specifies their definition using `define-syntax` [1]. However, its core syntax forms still include the following [2]:

  expression = variable
    | literal
    | procedure call
    | lambda expression
    | conditional
    | assignment
    | derived expression
    | macro use
    | macro block

... and there's a whole sub-grammar for specifying transformers (macros):

   =
      (syntax-rules (*) *)
   = ( )
   = 
     | (*)
     | (+ . )
     | (*  )
     | #(*)
     | #(*  )
     | 
   = 
     | 
     | 
     | 
   = 
     | (*)
     | (+ . )
     | #(*)
     | 
   = 
     |  

Being able to write or evaluate Scheme fully requires an understanding of all of these distinct syntax forms.

[0] https://docs.racket-lang.org/reference/syntax-model.html#%28... [1] http://www.schemers.org/Documents/Standards/R5RS/HTML/ [2] http://www.schemers.org/Documents/Standards/R5RS/HTML/

Yes. It’s similar to the difference between a mechanic and an engineer: a mechanic figures out something works, but the engineer can then take the next step to discover/know how. If someone cannot articulate or identify advantages, then they are pushing unproven, possibly wrong “religious” beliefs like a “mechanic.” Zealous communinal reinforcement is political, Macaroni and silly when there are no convincing arguments other than “because it’s new” or “because.”