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: <Cx5uFu.4yu@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: <Cwsy26.Et2@cogsci.ed.ac.uk> <36g8e6$2f4@relay.tor.hookup.net> <19940930T085535Z.erik@naggum.no>
Date: Tue, 4 Oct 1994 18:09:29 GMT
Lines: 69

In article <19940930T085535Z.erik@naggum.no> Erik Naggum <erik@naggum.no> writes:
>[Bob Hutchison]
>
>|   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.  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.
>
>this gave me an idea, since I don't think hardware is easy.  what happens
>in the real hardware is incredibly complex, and at the >100MHz speeds we're
>enjoying now, it is not a piece of cake to deal with, even in the friendly
>ALU, which isn't anymore.  now, we have been able to formulate a relatively
>simple model of how the hardware works, of what the hardware processes take
>as input and give as output, even though real life is nowhere near this.  I
>believe it is this model that C has managed to exploit, and LISP has not.

What is the model?  Can you give us a brief description?
I can think of many somewhat different models, and I'm not
sure just which sort you have in mind.

>one could even argue that the C model is employed at the hardware level,
>and thus makes hardware understandable in terms of software concepts.
>(somewhat akin to the interesting flow of ideas between models of the brain
>and models of hardware.)

I don't know about that.  For instance, hardware that employs a C
model would presumably be byte-addressable, and many machines have
not been.

>for me, programming in MACRO-10 on the DEC 10 some 10 years ago provided an
>interesting insight into some of the things in Common LISP today.  such as
>the constants used in the `boole' function.  small things, but so familiar
>that they made me laugh with recognition.  LISP is hardware, too!

Note too that on 36-bit machines with 18-bit addresses, a cons
could fit in one 36-bit word.  I didn't use DEC 10s, but I did use 
a different 36-bit machine, a Honeywell 635 (and later, related
models).

One of the things I wrote in Lisp was an assembler for use within
Lisp.  (Such assemblers were often called LAP -- Lisp Assembly Program --
in those days.)  It was a very easy program to write, contrary to
the impression one might get of Lisp's natural application areas.

>I don't know about any LISP Machines, but I wonder: was the hardware model
>on those machines equally susceptible to the C model, or were they "tuned"
>to the LISP model?

They were tuned to the Lisp model to an extent.  For instance, they
worked with tagged pointers and "generic" arithmetic.

>|   I think we will always have languages for programming hardware and
>|   languages for programming software.
>
>well said, but maybe what we have now is hardware that supports languages
>for programming hardware, to the _exclusion_ of hardware that supports
>languages for programming software?

I don't think so, because I think the usual hardware (RISC machines, etc)
works fairly well for Lisp-like languages.

-- jeff


