Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!lam
From: lam@uicbert.eecs.uic.edu
Newsgroups: comp.lang.scheme
Subject: Re: in defense of C
Message-ID: <82000007@uicbert.eecs.uic.edu>
Date: 8 Mar 90 20:36:00 GMT
Lines: 54
Nf-ID: #R:<9003012059.AA11786@schizo.samsu:-39:uicbert.eecs.uic.edu:82000007:000:2218
Nf-From: uicbert.eecs.uic.edu!lam    Mar  8 14:36:00 1990


/* Written  1:35 pm  Mar  1, 1990 by gjc@mitech.COM in uicbert.eecs.uic.edu:comp.lang.scheme */
/* ---------- "in defense of C" ---------- */
In defense of C?
(Or an apology for small extensible languages with minimal overhead
 and minimal required runtime libraries).

The key here is the phrase "equivalent program in Pascal" coupled
with the extremely important suggestion I made, which is that C
could be used like you use lisp.

You say C has no array bounds checking. (In a way, big deal,
certainly the Lispmachines had extremely good low-level checking
of that nature, but it didn't keep the software or user from
being able to "... let machines crash or behave strangely" as Steele puts it).

It is so easy to build up error-checking routines from
non-error-checking primitives. Is that not what we do in lisp? (Maybe
we only *used* to do it, a lost art?) Here are some declarations from
some code I use every day:

struct bitarray
{long width; long height; char *data;};

int bitaref(struct bitarray *,int,int);

void bitaset(struct bitarray *,int,int,int);

struct bitarray *cons_bitarray(long,long);

Now, with prototype-enforcement there is absolutely no way my program is
going to crash or behave badly if I use these three guys, cons_bitarray,
bitaref and bitaset. 

The prototype-enforcement makes sure I'm not calling these on data
that are not bit arrays and integers. My C-compiler can inline these
and remove redundant error checking in many case.

I claim: A good engineer can generate a much richer and more useful set of
subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE.

... especially compared to those those languages who's references manuals
start overflowing into multiple volumes!

On the subject of I/O primitives. "Gets" is one of those line-at-a-time
(what I called mainframe-style) procedures. Not what I had in mind (also,
not really what you should be calling primitive). Better to think in terms
of  getc and putc, or read and write, or XGetNextEvent.

-gjc

p.s. "... let machines crash or behave strangely", personally *no* I
don't use the Macintosh and try to avoid writing Unix kernel code.
/* End of text from uicbert.eecs.uic.edu:comp.lang.scheme */