Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cme!cam!ARTEMIS
From: miller@GEM.cam.nist.gov (Bruce R. Miller)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp, SOME, EVERY...
Message-ID: <2876612233@ARTEMIS.cam.nist.gov>
Date: 27 Feb 91 02:57:13 GMT
References: <1991Feb26.213445.15460@aero.org>
Sender: news@cam.nist.gov
Followup-To: comp.lang.lisp
Organization: NIST - Center for Computing and Applied Mathematics
Lines: 39


In article <1991Feb26.213445.15460@aero.org>, Scott "TCB" Turner writes: 
> A number of people have responded to this with comments of the sort 
> "C has immense numbers of functions in libraries, and people deal 
> with that..."

Not all of them do!

> I don't think comparing Common Lisp's plethora of built-ins with
> library functions in other languages is completely relevant.  For the

Nor completely irrelevant.

> most part, library functions are not general programming constructs.
> They perform specific computing tasks such as i/o, database retrieval,
> statistical manipulations and so on.

Dont common Lisp functions perform specific computing tasks?

> There's no cognitive difficulty with that because there is still a one
> to small mapping from tasks to functions to accomplish those tasks.
> ...
> In Common Lisp, the mapping tends to be one to many. 

Hmm. I'm not too sure about your mappings, there.
Perhaps this C isn't the ultimate standard, but in the C I've got to
play with, you get two partially overlapping sets of IO functions: one
using *FILE and the other using `handles'.  It seems that every time I
wanted to write a program involving IO, 1/4 the functions I needed were
ONLY available using handles, another 1/4 ONLY available using *FILE.
What fun!

>  ...
> Part of the problem seems to be lack of restraint on the part of the
> design committee.  

Yeah, my thoughts exactly!

[Not to say there isn't a bit too much redundancy in CL, but still...]