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: <Cx5xsA.681@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: <35urdq$31p@relay.tor.hookup.net> <Cwsy26.Et2@cogsci.ed.ac.uk> <36g8e6$2f4@relay.tor.hookup.net>
Date: Tue, 4 Oct 1994 19:21:45 GMT
Lines: 236

In article <36g8e6$2f4@relay.tor.hookup.net> hutch@RedRock.com (Bob Hutchison) writes:
>In <Cwsy26.Et2@cogsci.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>>In article <35urdq$31p@relay.tor.hookup.net> hutch@RedRock.com (Bob Hutchison) writes:
>>>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.
>
>OK, I agree I am not being clear :-)  Any attempt to correct this may
>lead to disaster, but here goes...
>
>What I mean when I say 'hardware' is something with a very low level
>of abstraction (maybe?)  Perhaps high degree of concreteness?  What
>happens at this level is very well defined and is easily translated to
>common knowledge.  For example, most people understand what adding
>two integers together means and what to expect as a result.

But why doesn't that work just as well for Lisp?  Indeed, you can
go further in many Lisps without running into issues of word size.

>  Writing
>a program in C largely involves manipulating things at this level.  Of
>course C supports 'aggregations' (I need words :-) of these manipulations
>in the form of things like data structures and functions, but it doesn't
>go too much beyond that.
>
>What I meant when I said that lisp and other high level languages provide
>support 'software oriented' programs, was that lisp provides support for
>constructing 'aggregations' of these 'aggregations'.  It isn't perfect, but...
>For example, scheme allows you to manipulate functions as you would
>any other data (type?), it has continuations.  Some languages support
>concurrency in the language (Erlang, BETA) rather than as a library.

In C, you can put functions (or ptrs to them -- one of C's complexities)
in structures, pass them as arguments, and return them as results.
C doesn't have closures over variables, but neither do some Lisps.

In any case, someone learning Lisp doesn't have to learn everything
at once, so I don't see why closures have to be an obstacle.

>Furthermore, languages like lisp and others, are designed expecting
>programs to be hierarchies of this kind, and so support it with
>strange things like call-with-current-continuation.

Most Lisps don't have call/cc.  What they have is similar to
setjmp and longjmp in C (but simpler).

(Why simpler?  Don't have to declare a jmp_buf, don't have to
worry about what happens to register vars.)

>>>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 university I attended (still) presents basic CPU architecture
>very early (brief overview in first year, details first thing second year)

Humm.  How common is it to teach about hardware before teaching
about programming?  I didn't encounter that order of doing things.

>I think you probably had a pretty good idea of some simple concepts
>from hardware.  The idea of a data store, arithmetic, updating values,
>precise sequential operation (probably this is the first hard thing to 
>really learn, it is understood early, but...).  Stuff like that.  You had
>used a calculator I would imagine.

Actually, I wrote programs before I'd used (or even seen) a
calculator.  (This may show how old I am.)

>   Even using paper to do scratch
>calculations on would provide some (small) useful model to the
>learner. 

I find this very odd.  Doing calculations on paper gives a useful
model for C but not for Lisp?

> (If you had a good grounding in doing calculations on paper,
>would it ever occur to you that you could group some of those written
>lines of calculations, and perform calculations on them in turn?  

Isn't that what one does in high school algebra?

>Not likely, and I think this is similar to a C programmer's difficulty in
>thinking of manipulating his programs -- you can't do it in C, so you
>don't think about it.)

The C compiler manipulates programs.  Do people suppose it works
in a mysterious way?  Don't they think "cat" and "grep" are programs?

Anyway, you can use "substitution macros" in Lisp if you want.

>>>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.
>
>Sure, but a novice doesn't know those models.  Have you seen many
>novice programmers that can handle even coroutines much less
>a thread?  Actually, I think my personal model of a thread is an
>abstract one, not concrete -- I know how it is implemented because
>I need to, but that knowledge isn't used when designing software.

So why count things a novice won't learn against Lisp but not
against C?

>I don't want to get too carried away with providing 'hardware' models
>for programmers.  I think the more abstract models are better suited
>for the job.  However, I think it is useful to think of these differing
>models when wondering why very good C programmers cannot
>immediately jump into lisp and other high level languages.  And,
>perhaps, there is enough to this that it can help these programmers
>make that transition.

I don't know about immediately jumping, but novices and good
programmers may face different problems.

>>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.
>
>Really?  My very first experience with C was to port it to a machine
>I had to work with.  It was the only compiler that I know of at the
>time that was even remotely portable.  I learned C later.  That
>C compiler was awfully simple.  I expect that ANSI C requires
>somewhat more sophisticated techniques.

When I was in high school, I wrote a Lisp interpreter in Basic.
It was a couple of pages long.  I couldn't have written a C compiler,
or at least I'd have found it much harder.  I'm surprised that you
think a C compiler might be easier.

>>>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.
>>
>>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.)
>
>I hope I've mostly answered this.  There are other examples, scheme
>and CL and others, have a number system that is quite independent
>of the underlying hardware. 

They use ordinary floats, and arbitrary precision ints can be
easier to understand, rather than harder.

> This is both a good thing and a bad thing.
>There are any number of programmers intensely put off by this lack
>of 'control' over how their numbers will be represented.

I feel that I can sufficiently control how numbers are represented
in the Common Lisps I use.  Anyway, you again seem to be moving
to experienced programmers rather than novices.

>>>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.
>
>Is that what you meant? 

Yes.

>Interactive environments like lisp and smalltalk are clearly winners over
>the compile/link/debug cycle of C (or the compile/link/reboot cycle in
>Windows -- yes, it is even more dramatic in windows).  However, some
>of these C/C++ compilers on PCs are getting awfully fast.

I was thinking of the interactive rather than the speed.

>>>>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.
>
>Yes, but parenthesized prefix syntax, lambda, recursion, eval, quote,
>and 'evaluates its arguments' (or not) are in support of manipulating
>software by programs.

Prefix syntax may make software easier to manipulate, but so what?
As for the rest, only eval looks to me like support for manipulating
software.  I don't know why you think that of the rest.  For instance,
consider this in Basic:

  let a$ = b$
  let a$ = "b$"

Would you now say quotation in Basic is "in support of manipulating
software by programs"?

>I think we will always have languages for programming hardware
>and languages for programming software.

I think it's an interesting data point that I spend lots of time
programming in Lisp, also program in C, and find that position odd.

-- jeff
