Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.alpha.net!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!xlink.net!news.ppp.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: Lisp considered unfinished
Message-ID: <1995Jun9.085359.11701@wavehh.hanse.de>
Organization: The Internet
References: <ddyerD9pqo2.GKx@netcom.com> <3r0v3d$bvp@tools.near.net> <3r5ads$60l@news.aero.org> <3r5kfn$4nh@camelot.ccs.neu.edu>
Distribution: inet
Date: Fri, 9 Jun 95 08:53:59 GMT
Lines: 47

futrelle@ccs.neu.edu (Robert Futrelle) writes:

>The language is only as big as you make it.  If the sample code you
>give the students to guide them in their work only includes a handful
>of functions, growing to 40 or so, then why should they be confused.
>Don't just hand them Steele and say, this is it.  There are numerous
>texts that only teach a core set of functionality.

I oppose to this view. I couldn't get produtive in Lisp with the
functions mentioned in Winston/Horn and Koschman. Simulating existing
functions by combining simpler ones is a waste of time. The worst
thing was I couldn't understand other people's code because I didn't
know many functions/macros.

It took reading CLtL2 to be productive. With productive I mean a
portable application with acceptable fast I/O and optimized inner
parts and usage of standard CL elements where they exist (to be
readable for others and for me at a later time).

[...]

>Lisp doesn't tend to break on "low-level" things because there
>are reliable parts of the Lisp system that handle pointers and memory
>allocation for you.  If you write several layers of interacting
>macros, you could be making trouble for yourself.  See Paul Graham's
>book On Lisp for discussions of how you can hang yourself writing
>macros.

For me, Common Lisp systems break relativly often, more often than my
(GNU) C compiler.

This causes me to do my Lisp work on UNIX where I have several
compilers availiable to check them against each other (and against my
unsufficient knowledge of Common Lisp that causes many programs to
fail, too).

The nature of working in Lisp, in an integrated environment where a
crash in a compiler or debugger/inspector/whatever causes all editing
sessions to be terminated, too make the situation worse as in C, where
a chrashing compiler doesn't harm other emacs buffers (of course, that
doesn't apply to Borland C++ :-).

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>. No NeXTMail, please.
 Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a 
 private address. At (netless) work programming in data analysis.
