Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!panix!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston.ans.net!pipex!dircon!rheged!simon
From: simon@rheged.dircon.co.uk (Simon Brooke)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
In-Reply-To: dsc@u.washington.edu's message of 15 Oct 1994 15:53:52 GMT
Message-ID: <CxrB0E.zJ@rheged.dircon.co.uk>
Organization: none. Disorganization: total.
References: <36g8e6$2f4@relay.tor.hookup.net> <781909250snz@wildcard.demon.co.uk> <37ga57$9v8@disunms.epfl.ch> <gclement-1210940859010001@155.50.21.58> <37otug$j8g@news.u.washington.edu>
Date: Sun, 16 Oct 1994 08:17:01 GMT
Lines: 55

Wee laddie, if you don't know what you're talking about, don't post.

In article <37otug$j8g@news.u.washington.edu> dsc@u.washington.edu (Devin Cook) writes:

   This comment is very intresting because it is exactly the opposite of what
   I have read on lisp.  With Lisp, you work from the bottom up, so you start
   to build so small utilities until your ready to actually figure out how to
   use them.

With LisP, you start wherever you like. The bottom up approach is
possible, and may be the best way to proceed when you really don't
know what you're doing, but many people work top down.

   Here is my two cents worth:

I wouldn't pay two cents for ignorance.

   Lisp is slow and comes with two much baggage.  The number of keywords you
   need to get going is overwhelming.  Also, since Lisp is weak at I/O, its
   hard to write small programs to play with.  ( I mean its hard to get excited
   about a language when your limited to writing code that find the next item
   in a sequence when you start out!  Yawn.... )

At the time of the launch of the SPARC machines, Sun claimed that
their Common LISP compiler generated faster code than their C
compiler. Generally, however, it seems to be agreed that well written
Common LISP programs will run a little slower than equally well
written C programs -- but the factor will be better than 1.75:1.
Common LISP, because of its size and complexity, is not likely to be a
fast LisP, although I haven't really looked at comparative benchmarking.

There are no keywords in LisP, so the number your need to get you
started is nil. The core of LisP comprises about a dozen functions, with 
which everything else can be built.

   Debugging is also a real pain.  (Trace) just doesn't cut it in this day
   and age.  The problem is that with properly written Lisp code, ( at least
   this is what it says in the books! ) there are NO intermediate results to
   examine and tell you why some code doesn't work. In C or Borland's Pascal
   ( my favorite language ) I can break up an expression as small as I like
   and watch the variable I'm intrested in.

In any decent LisP you can watch the stack, where all intermediate
values are held. You can watch or break any arbitrarily small
expression, and edit it at source level within the break, with all its
runtime information available, to fix the problem. You can then
continue the execution with the corrected code. You can't do this in
any ALGOL family language.

If you want a small, fast, efficient LisP in a DOS environment, you
might look at MuLISP.

-- simon@rheged.dircon.co.uk

			-- mens vacua in medio vacuo --
