perm filename LLX[FOO,LMM] blob sn#092636 filedate 1974-03-16 generic text, type C, neo UTF8
C00001 00001
C00002 00002	Letter to Clark Weissman at 
C00008 ENDMK
Letter to Clark Weissman at 
System develoment corporation
2500 colorado ave
santa monica cal 90406

Dear Clark,

Hi, how are you? Long time no see and all that Your
girls must be fast approaching young ladies.
Ellin must be a teenager. Say hi to them for me.
will try to get to see you guys soon.

Re your letter. Havent had time to respond in all this
time as I have been working on my own opus, new INTERLISP
reference manual. I am sending you a copy. As you
can see, it's thorough. 

I have long had strong ideas about introducing people to
LISP. Many of them at direct odds with your book,
if not your own views. I have taught LISP to a numberof
people, of varying backgrounds but usually fairly high
degree of intelligence. IN fact, I am going to teach
another course when I return from an up coming
trip (this time we are going to videotape it).
I have even considered writing my own primer, but it
is just not high enough on my list.

Basically, I think that your primer is ou of date not
with repsect to content but to style. You stress skills
such as being able to balance parentheses, draw boxes,
and compute CADDAR's and CDDADR's which are not of much
use today, even for professional LISP programmers,
and certainly not very interesting or rewarding to
new users. They correspond to scales for playng music,
except that scales do develop certain skills that are 
necessary, and the above LISP skills are no longer necessary,
at least not in INTERLISP (see chapter 23 in manual on CLISP).
Moreover, they do not capture the flavor and aesthetics
of LISP. What I like to do in teaching is not to
worry abut syntax, parentheses, dot notation (see the
record package in chapter 23 for an exmple of whatis
being done with data-less programming in LISP, i.e. 
even if one is employing data structures
other than simply lists, where it is important whether
an element is stored in CADDR or CDDDR, the chore
of worrying abut accessing and retrieving is handled
by the system from user declarations).
Instead, I plunge directly into recursion. Five minutes
after I start, during which time I wave my hands
and say there is this thing called a form, which 
is either an atom, or a list, in which case the first
element is the name of a function and the rest 
are its aaguments, also forms. etc., anyway five minutes
later that I am saying, ok let's define factorial.
That's where the essence is. How much power is available
in the notation, how clean the expression of the recursion.
I then work through several other examples, and then
let users start writing functins. Never mind the LAMBDA,
DEFINE, or even parentheses errors. That will come. IN fact
in a clever system, it seems that a DWIM like facility
should b able to correct those kinds of errors. 
We have not yet progressed that far, but with CLISP,
it is not so important. The user writes in CLISP, then
can see what the equivalent LISP is. It is much easier
to read LISP for a beginning than to write it.
 For example, if the user were to write MEMBER
for the first time, he would say
Anyway, whether you write in CLISP or not is not as important
as getting to the heart of the matter.

I think that you were obviously influenced by the lack
of really interactive systems at the time that
you wrote your book, certainly atthe timeyou learned
LISP. I am not sure how much contact you have had
since that time. I would suggest, if you are interested,
that you either log in on the net and play with some
INTERLISP, or perhaps aarange a trip up here to
talk about it. I would certainly like to see a LISP Primer
which teaches how to program in LISP< rather than
emphasizing what is to me fairly useless skills.