Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!swiss.ans.net!news.dfn.de!Germany.EU.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: <Cx40LB.6CA@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> <780827318snz@wildcard.demon.co.uk>
Date: Mon, 3 Oct 1994 18:27:10 GMT
Lines: 94

In article <780827318snz@wildcard.demon.co.uk> cyber_surfer@wildcard.demon.co.uk writes:
>> 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.
>
>I agree that an interactive language is better, but I only have
>my own experience with an interactive Basic to judge this by.
>I'd say that the batch compile approach used by C is just a more
>complex way of doing the same thing as typing "run" in Basic.
>It only looks different, but that's an implementation issue.

Sure, its the "same thing" in a sense, especially if the Basic
is compiled.  But it's not the same in terms of what the user
has to do to get a program to run.  If what the user sees is
different, it's not solely an implementation issue.

>PJ Brown's book Writing Interactive Compilers and Interpreters
>explains how an interactive language like Basic (or Lisp) can
>also use a compiler, and make it transparent. I believe there
>are Lisp and Smalltalk implementations that use such techniques,

PopLog Common Lisp, for example.

>altho I know that some Lisps require the compiler to be explicitly
>invoked - a bit like a C compiler, in fact:
>
>(edit)                             ; edit
>(compile-file "foo.lsp")           ; compile
>(load "foo")					   ; link
>(foo)							   ; run

Or consider (using Franz lisp)

  shell% emacs foo.l
  shell% liszt foo
  shell% lisp
  > (load 'foo)
  > (foo)

or even

  shell% liszt -r foo
  shell% foo

which are even closer to the C model.  

>    That's why I'm interested in Dylan,
>as it seems to promise _both_ runtime speed and an interactive
>incremental compiler in the one language. Unless Lisp systems can
>offer me the same features, I'll probably switch to Dylan.

Why do you think Dylan has an advantage as a language over other
Lisps?  The parsing task is more complex, so it ought to be slower
overall.

>> 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).
>
>I not only found a usable subset, but one that I could also
>implement. It's written in about 10,000 of C and uses a subset
>of about the same size as XLISP, but consisting of different
>features. For example, I've yet to add arrays or structures,
>but I have multiple values and full SETF semantics.

>> But 2-5 are presentation problems, not language problems.
>
>Agreed. Just look at Dylan! Even if that's not "Lisp", it's a
>good example of how to do it _right_. In my humble opinion,
>of course.

I find it difficult to call a language "right" when it makes
the transition between ";" and "," in a "select" significant.  :->

> I'd rather use Dylan than most Lisps I've used,

I find this impossible to say, since there are no implementations
of Dylan available to me.  (There are some implementations of
"Dylan-like" languages, of course.)

>> I'm tempted at this point to try to write a "Lisp for C Programmers".
>
>That would be an excellent idea! Good luck, if you do it. If you
>want a co-author, I'm available. :-) If course, you might be better
>of without me, as I have some odd ways of working. So my friends
>tell me, anyway! (But they all use C...or Basic.)

Well, I need to find out some more about why C is supposed to be
easier and about the machine models that get used along the way.
Perhaps Comp.lang.lisp will provide this.

-- jeff
