Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!bbn.com!mthome
From: mthome@bbn.com (Mike Thome)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Keywords: resistance to lisp
Message-ID: <40732@bbn.COM>
Date: 1 Jun 89 13:03:15 GMT
References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk> <1028@syma.sussex.ac.uk> <487@skye.ed.ac.uk> <11917@well.UUCP>
Sender: news@bbn.COM
Reply-To: mthome@vax.bbn.com (Mike Thome)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 21

In article <11917@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>     Most of the attempts to make LISP look like Pascal or one of its
>descendants result in a syntax that is more, rather than less, painful.
For example, take a look at Logo...  When I was learning lisp, at first
it was its syntactic consistancy which was probably the most attractive
attribute.

>On the other hand, the fact that data and programs have the same 
>representation in LISP really doesn't seem to be used all that much
>any more.  It was felt to be terribly important at one time, but today,
>it just doesn't seem to be a big issue.
>					John Nagle
I must disagree here - any macro (including most setf expanders) will
depend on the similarity between data and program. Personally, I've been
working on a number of different projects which build (sometimes compile)
routines at runtime.  While this might even be unusual, lisp is, after
all, one of the very few (only mainstream?) language which can do this -
I have a hard time imagining what it would be like to try to implement
one of these systems in a "conventional" language.

Mike Thome (mthome@bbn.com)