Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
Message-ID: <Cwsy26.Et2@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <35kbl8$8ni@relay.tor.hookup.net> <CwJ88z.K2E@cogsci.ed.ac.uk> <35urdq$31p@relay.tor.hookup.net>
Date: Tue, 27 Sep 1994 18:58:53 GMT
Lines: 215

In article <35urdq$31p@relay.tor.hookup.net> hutch@RedRock.com (Bob Hutchison) writes:
>In <CwJ88z.K2E@cogsci.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>>In article <35kbl8$8ni@relay.tor.hookup.net> hutch@RedRock.com (Bob Hutchison) writes:

[...]

>>>I think that [...] C is easier for them to comprehend, but I don't think
>>> it is because it has easier abstractions.  I think it is because
>>>they can use the computer hardware itself as C's abstraction, that is,
>>>use a concrete thing as an abstraction -- what an illusion :-)  I guess
>>>that I think you are basically right that the novice has a difficult time
>>>forming a useful understanding of how the language works, but I think
>>>this is difficult for any language.  I think that in C's case the novice
>>>can cheat.

>>I like the idea of using a concrete thing as an abstraction, though I
>>suspect that many people have a somewhat abstract model of the hardware.

>>However:
>>
>>  (a) Novices don't necessarily know all that much about the hardware;
>>  (b) Novices (e.g. children even back in the days before they grew up
>>      with video games) have found it fairly easy to learn languages
>>      that aren't so close to the hardware (e.g. LOGO, Basic).
>>  (c) There are reasonably simple hardware-based models that work
>>      for Lisp.
>
>I don't know that it matters that their model of the hardware is abstract.

I don't either; I was just mentioning it.

>The model they have seems actually quite good at predicting what the
>hardware will do (CPU here, not IO devices so much).  If they can then
>translate that predictive model into a 'C' model, then they stand a
>chance of predicting what a C program will do.

I'm not sure what you have in mind here.  It sounds like you're
thinking of people who start by learning to program in assembler,
so that they have to predict what the CPU will do.

>Children seem to be an exception to everything to do with learning
>(do you have kids?).  They seem to be better at learning.

But do you think LOGO is hard for old folks to learn?  (How old
are people these days when they're learning C?)

>Use of a hardware model to aid in learning a programming language
>would apply to most languages.  I don't doubt that there is a suitable
>hardware model to explain lisp, but I don't think it is the same one.
>Unfortunatly the one availble to a C programmer is the one taught,
>at least where I went to school.

Can you say something more about this?  I learned how to program
before I knew abything about how the hardware worked.

>The other difficulty with languages like the lisps and other high level
>languages, is that they provide a fair bit of support for the
>development of 'software'.  I wonder what a hardware model of
>a continuation in scheme or ml would look like, or a non-deterministic
>program written using them?  

What is the hardware model of a coroutine or a thread?  There are
such models, of course, and there are similar ones for continuations.

But I'd like to separate the question of learning Lisp from that
of learning all of Lisp.  After all, it may be that some parts are
hard to learn while others are not.  A conclusion along those lines
would be (if it does turn out that way) more precise and useful.

>What is the hardware model for an
>abstract data type for that matter?

Lisp doesn't have those.  (Some Lisps might, of course.)

>     What is the hardware model
>for a CL macro?  (this macro idea is one that seems to be somethin
>that a C programmer has an awful time comprehending, possibly
>it is just an 'I don't believe you' problem rather than a 'what would
>I do with it?' problem)

What is the hardware model for a C macro?  In any case, you have to
explain it (sooner or later) as textual substitution.  A CL macro is
(a) taking some source code represented as Lisp data, (b) calling
a function that returns some different source code -- the expansion,
(c) processing the expansion instead of the original code.  In
some ways this is simpler than C, because the expansion mechanism
is Common Lisp rather than something different.

I think it's much easier BTW to understand a Lisp interpreter
(for a suitable simple Lisp) than a C compiler (even for a smallish
subset of C).  So in some ways it's easier to explain how Lisp
works.

>>This makes me question whether C wins because novices can use
>>the hardware as a "cheat".
>>
>>It's important to bear in mind that some Lisps -- e.g. Common Lisp,
>>InterLisp -- are large and full of rather complicated stuff while
>>other Lisps are very simple.  They're smaller and simpler than C; and
>>Lisp implementations tend to be interactive, which makes it easier to
>>try things out.  It's also easy to set up Lisp to use the "just run
>>it" Basic approach.
>
>Scheme is relatively new to me, I assume that it is one of the simpler
>lisps you refer to.  While it is a nice simple clean language that I find
>rather appealing, it supports a programming style that, in my opinion,
>is fundamentally a software oriented style, not a hardware one.

Scheme *is* fairly simple, especially compared to Common Lisp.
But there are simpler Lisps, e.g. without call/cc.

I'm intrigued by the phrase "a software oriented style".  Could
you say something more about it?  (I assume it's related to your
point about macros.)

>Is there a simple model of a scheme 'machine' that would allow
>someone to predict behaviour of the software?  I would have thought
>that scheme is its own best model.  Wasn't that kind of the point of
>scheme?
>
>My first reaction to the 'just run it' approach to lisp was a bit negative.
>But when you think about it 'just running' lisp is probably not much
>different than the kind of C programming we get.  It also holds the
>promise that as the programmer gains experience the other aspects
>of lisp become available.

Well, I think an interactive Lisp is better when learning the
language.  But the Basic model is fairly simple.  You have the
program source, you type "run", and it runs.  C follows a more
complex compile-and-link model.

>>Nonetheless, I think that in practice Lisp *is* often hard to learn.
>>I'm not sure I can say whether it's easier or harder than C.  It
>>would depend, for one thing, on how much of C and how well it must
>>be understood, and on how much of which Lisp.
>
>I can tell you that my problem with CL was finding a subset of it
>that I could do something with.  

I think that's a very serious problem with CL.  It's difficult
to extract a nice subset, especially if you're new to Lisp.
Textbooks ought to help there, but many of them cover too
much of the language (IMHO).

>                                 CLtL was not much use for that.
>It wasn't until I came across Paul Graham's "On Lisp: ..." that things
>'switched on' with CL.  Scheme was much easier.

I think it's often very hard to find things in CLtL.  Looking up
a function name in the index and turning to the appropriate page is
often not enough.  For instance it may talk about something that
"satisfies the test".  That phrase is explained somewhere else
(at the start of the chapter?).  So CLtL has some problems as
a reference manual, and it has other problems as an introduction.

>>Anyway, in my view the following factors are responsible for much
>>of the difficulty:
>>
>>  (1) The fully parenthesized prefix syntax.
>>  (2) Peculiar, unfamiliar names such as car, cdr, cond, and lambda.
>>  (3) Hard topics such as recursion that tend to be mixed in with
>>      learning Lisp.
>>  (4) Confusing presentations of eval, quote, and "evaluates its
>>      arguments" that make the question of what gets evaluated
>>      seem much harder than it is.  (The syntax also contributes
>>      to this, because it's so uniform.)
>>  (5) Teaching that has a mathematical flavour and emphasises the
>>      functional side of Lisp.  This is great for some students but 
>>      makes Lisp much harder for others.  E.g. box-and-arrow diagrams
>>      are tied to the discussion of mutation, and hence aren't
>>      available when people are first trying to figure out what lists
>>      are.  (A number of odd models can result from this.)
>
>Most of these points are illustrations of what I mean by support
>for 'software'.  These are software ideas not hardware.  

But 2-5 are presentation problems, not language problems.

Perhaps we could discuss briefly how C is taught?  I learned C
from a book, as I did for most other languages I know, so I don't
know how it's normally done.  (Though I've taught Lisp and Basic.)

I'm tempted at this point to try to write a "Lisp for C Programmers".

>>Some of these are already questions of how Lisp is taught.  Others,
>>such as the fully parenthesized syntax, require more care in
>>presentation than they often receive.  It will also be interesting
>>to see how much difference it makes to change the syntax (as in
>>Dylan).
>>
>
>This will be interesting. Though what about ML?  It has been around
>for a while now, what is the experience with that?

I don't think there are enough implementations.  SML of NJ,
though excellent, is rather large.  I'm not very well-informed
on what's available, though.

>I think that this discussion is interesting, and possibly even useful,
>the real issue with lisp is social and political.

I agree.

I don't really expect Lisp to become super-popular, if Lisp means
Common Lisp, or even Scheme.  I think the syntax will always work
too well against it, even though many people find it more readable
rather than less (I am one).  But Lisp can have a different syntax,
and there are Lisp-like languages (whether we consider them in
the Lisp family, strictly speaking, or not) such as Pop and Logo
and Dylan that illustrate this (as does the never fully realized
Lisp 2 and various alt syntaxes construted over the years).

So I think there's still hope for Lisp-like languages.

-- jeff
