Newsgroups: comp.lang.lisp
From: cyber_surfer@wildcard.demon.co.uk (Cyber Surfer)
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!europa.eng.gtefsd.com!howland.reston.ans.net!news.sprintlink.net!demon!wildcard.demon.co.uk!cyber_surfer
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>
Organization: The Wildcard Killer Butterfly Breeding Ground
Reply-To: cyber_surfer@wildcard.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
Lines: 108
Date: Tue, 4 Oct 1994 20:49:33 +0000
Message-ID: <781303773snz@wildcard.demon.co.uk>
Sender: usenet@demon.co.uk

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. When you compare two different compilers, I find it helps
to appreciate these issues. If you merely use a compiler, you can
worry about other things. Programmers like to compare their compiler
with other compilers, and even compilers for other languages. That's
when this becomes important, I find.

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.

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

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

Since I'm expected to programme in C++, any language which has
a chance of doing the same thing appeals to me. It's a question
of what the language offers, and the potentially smaller foot-
print could be important.

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 should qualify my hopes for Dylan, as it would depend
on the actual implementations available, and how they compare
with existing language systems, like C++ and Smalltalk.

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

I've seen and used far worse language feature designs. ;-)

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

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

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

I don't think it is easier, it's just that programmers perceive
it that way, or that'sthe language that their employers want
them to use, so they use it. I'm told by my friends who are in
network support that some people simply accept what they're told
as "gospel", and then never question it. If they're asked why
they do something, they can't explain it. I'm also told that
these people become managers and then tell the same things to
the next generation of support people! Perhaps that's a good
model to use for understanding what happens with C programmers?

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.

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.

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.
-- 
http://cyber.sfgate.com/examiner/people/surfer.html
