Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!ucbcad!ucbvax!UNIX.SRI.COM!jperry
From: jperry@UNIX.SRI.COM (John Perry)
Newsgroups: comp.sys.apple
Subject: The C language
Message-ID: <8705271914.AA18536@sri-unix.ARPA>
Date: Wed, 27-May-87 15:14:54 EDT
Article-I.D.: sri-unix.8705271914.AA18536
Posted: Wed May 27 15:14:54 1987
Date-Received: Sat, 30-May-87 06:24:42 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 94


     I have actually written about twice as much C code as Pascal or
Modula-2 code and so my criticism of C is not made solely at an "airy"
theoretical level.  
     You say that "If C is so terrible, then how do you explain so many
commercial software developers switching to it?".  I thought I answered
that in my previous memo i.e. that some languages have dirty details
that make them so desirable in a practical sense that programmer's
are willing to overlook even the grossest of structural defects.
     Turing and/or Modula-2 have failed to hold sway in the commercial
world for the very simple reason that they arrived after both C and
Ada and simply haven't had sufficient people to toot the horn for them.
That's all it is --- C got their first and, like the inertia of FORTRAN
programmers to learning a different language, C programmers don't want
to change either (and I know plenty of them who HATE C but just don't
want to make the effort to get out of their bind).  Why?  Well, as you
put it, C is "good enough" --- the typical sunk-cost outlook --- another
tool has to be 100% better to justify a changeover.
     C, when examined closely, is so full of inconsistencies and 
unnecessarily cryptic syntactical finesses that, and I will reiterate
my practical observation, that even good C programmers can be seen
consulting a C manual even after several years of practice!  I hate to
get bogged down in another "features" discussion but it seems I'm being
drawn in to it --- so here goes.
     First, inconsistencies in parameters of library calls.  Why is it
that, in an fprintf statement, the file is the first parameter but in
a putc statement it is the SECOND parameter?  And why, oh why, does C
have to be different than the rest of the world by making the destination
string be the FIRST parameter in string subroutines such as strcat?
Oddly enough, in the original Kernighan and Ritchie C book, their version
of strcpy has the destination string as the second parameter on page 100
--- why the change to the counterintuitive in commercial C?
     Second, inconsistencies in rules for structured data types.  Can
anybody give me a good reason why arrays cannot be assigned in assignment
statements as can structures?  Another artificiality that one must keep
in mind.
     Third, C's allowance of mixing pointer and array types leads to
abominably unreadable code.  In some UNIX sources I have seen such
mixtures leading to oddities like a[3] meaning "the third value after
where the pointer to a is currently pointing" rather than simply the
fourth value of the array.  Try reading this kind of stuff and keeping
your sanity.
     Fourth, the simple C data declaration:

          int   *pi;

gives you no clue whether pi points to a SCALAR integer or an ARRAY
of integers.  This kind of ambiguity does not exist in Modula-2
or Pascal where the declaration of pi would tell us whether we have
a pointer to a scalar or structured data type.
     Fifth, C's rules for initializing character arrays, especially
"ragged" arrays of variable length characters, seems to differ from
implementation to implementation.  
     Sixth, C allows an unreadable degree of programmer cleverness
as in such code segments as:

     strcpy(s,t)
     char *s,*t;
 {
    while(*s++ = *t++);}

Which relies on the artifact that a string terminator happens to be an
ASCII zero and that, since the value of an assignment statement is the
value of the left hand side, the while will terminate when NULL is
encountered.  C moguls actually ENCOURAGE this kind of "idiomatic"
expression e.g. Kernighan and Ritchie -- "Although this may seem cryptic
at first sight, the NOTATIONAL CONVENIENCE (my emphasis) is considerable,
and the idiom should be mastered ...".  
     By notational convenience they mean THAT IT CAN BE TYPED IN
QUICKLY!!!  And, of course, the "idiom should be mastered" if one is
to enter the pantheon known as "C cognoscenti" --- God forbid if
one's C code looks like that of a Pascal programmer!!
     I could rant on and on about the poor human engineering of the C
language (how many times have you gotten caught on  if a = c instead
of if a == c  or  *p++ versus (*p)++ ??) and get even further bogged
down in the "features" quagmire.  But to what end??  
     The "bottom line" of my complaints about C is that it is a
poorly engineered language which CANNOT be improved by continually
adding "features".  Its features are counterintuitive, poorly
human engineered in that they invite error, and literally beckon
the kind of cryptographic, "clever" code which seems to be ENCOURAGED
by its leading proponents.  On the other hand, I feel that the
basic skeleton structure of a language like Modula-2 is so sound that
the addition of precious few features and a couple minor language
changes would create a nearly ideal programming tool.
     But, it'll probably never happen because the artificialities
and ambiguities of C create the sort of mystique about the "difficulties
of programming" that programmers love.  Next to chess players, their
egos are the most insufferable.




                                                   John Perry