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!EU.net!uknet!festival!jeff
From: jeff@festival.ed.ac.uk (J W Dalton)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
References: <35urdq$31p@relay.tor.hookup.net> <Cwsy26.Et2@cogsci.ed.ac.uk> <780827318snz@wildcard.demon.co.uk> <Cx40LB.6CA@cogsci.ed.ac.uk> <781303773snz@wildcard.demon.co.uk>
Message-ID: <CxBFyD.3CD@festival.ed.ac.uk>
Organization: Edinburgh University
Date: Fri, 7 Oct 1994 18:42:13 GMT
Lines: 102

cyber_surfer@wildcard.demon.co.uk (Cyber Surfer) writes:

>In article <Cx40LB.6CA@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk "Jeff Dalton" writes:

>> 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.

>I agree. I was looking at it from the perspective of the compiler
>writer. [...]

>For example, if you compare an interative Basic with a compiled
>Basic, there are usually big differences. If the interactive
>system uses an incremental compiler, then there differences may
>be smaller ones. The programmer might not even notice the compiler.

Just FYI:
So far as I know, Dartmouth Basic always used a non-interactive
compiler.  But it was a fast compiler, and the model was that you
entered a program using some editor (one -- using line numbers --
was built into the command interpreter, which was a multi-tasked
system rather than a lot of spearate shells).  The you typed "run".
Many interpreters followed the same model.  

>>   shell% liszt -r foo
>>   shell% foo
>> 
>> which are even closer to the C model.  

>Which supports my belief that there are no real problems with
>"Lisp". There are only differences between dialects and their
>implementations.

I agree.

>> 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.

>Partly because Dylan can (or promises to) do some things that
>no Lisps availabe to me currently support. Sharing code at the
>class level is one feature that I'm particularly hoping will be
>used in Dylan implementations for Windows.

Why does CLOS not support this?

>I'm not concerned about the "parsing task", as I currently have
>use C++ and compile with enourmous headers defining large class
>heirarchies. An incremental compiler would help, but I know of
>no C++ compilers that support this. Even if Dylan's parser must
>be more complex than a C++ parser, that's nothing to make me
>worry. 

I meant compared to Lisp.  The parser s.b. simpler than one for C++.

>    I should add that most language systems are not available
>to be, and most of the "Lisps" that are available to me have not
>impressed me as much as the Smalltalk or Actor systems I've used.
>That may be because many of them don't use a GUI (yet), which I'd
>prefer, and that the ST and Actor systems I've used both had
>excellent GUI support.

Sometimes the GUI is part of the problem.  I'm all for having some
Lisps w/ fancy GUIs, but there should also be some alternatives.

>It may be worth looking at some books for C programmers about
>other languages, and see how they do it. When I've browsed thru
>such books they seem to adopt a model close to C, or whatever
>language they assume the programmer already uses.

>Another way could be to find some alternative model and to
>attempt to re-educate the C programmer. This is why I suspect
>that it's bette to catch someone before they learn C.

People used to say things like this: you can learn Lisp in a
day, or three if you know FORTRAN.  (That's more or less a
direct quote from the Eclisp documentation -- anyone ever
encounter that beast?  It was for DG Eclipse machines.)

>This reminds me of the Hope book I'm currently reading, which
>assumes no previous programming experience. I'm fequently
>suprised by how much it explains - it goes into far greater
>detail as far as the model is concerned, but without going
>to a lower hardware level. It _explains_ more about what
>is being done. Most books I've read assume a great deal of
>prior knowledge, even when they try to avoid that.

What books is that?  Still in print?  I'll get one if so.

>Roger Bailey seems to have anticipated far more of the things
>that someone knew to computers and programming may misunderstand.
>Using notes for teaching students may have helped, and the book's
>intro supports that. As experienced programmers, we might find
>it harder to think like a newcomer to programming, or like a
>newcomer to Lisp, or like a C programmer.

I *used* to understand what new programmers were like, but if
all this talk of hardware models is true they may have changed.
My encounters w/ new programmers were a number of years back.

-- jeff
