Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!ubc-vision!ubc-cs!manis
From: manis@ubc-cs.UUCP
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <1017@ubc-cs.UUCP>
Date: Tue, 21-Apr-87 14:58:42 EST
Article-I.D.: ubc-cs.1017
Posted: Tue Apr 21 14:58:42 1987
Date-Received: Thu, 23-Apr-87 23:51:38 EST
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP>
Reply-To: manis@ubc-cs.UUCP (Vincent Manis)
Organization: UBC Department of Computer Science
Lines: 81

In article <658@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes:

>> You left off reason (e), I hope, and that is "If you want Readability and
>> therefore Maintainability".
>
>A C program is no more readable to a C programmer than an assembler program
>is to an assembler programmer.  Ditto for maintainability.  The issues of
>Readability and Maintainability come back to points (c) and (d) above; in
>other words, whether we're talking about C programmers or assembler
>programmers.
I must respectfully disagree with these remarks. Admittedly much of the C I
have seen (say in mod.sources) is disgracefully written. However, I write C
as if it were Pascal. I am also a quite competent assembler programmer (for
several *dozen* different machines). I can read my C and Pascal code; I
cannot read my assembly code anywhere as well, even when it is carefully
written.

>The notorious lack of "commenting" by supposedly professional C programmers
>really compounds this problem.  Professional assembler programmers make dang
>sure their code is well commented, and the comments are maintained as the
>program is maintained.
Comments are not very useful in programming. I once maintained a BCPL
compiler which had almost no comments in it. The front end (parser) was a
model of clarity; the back end (code generator) was tangled, contorted and
used an immense number of coding tricks (it generated very good code,
though). The difference was the programmers; no number of comment lines
would have made that code generator clear. 

>> You forgot
>> 
>>    e)  Reducing the opportunity for bugs by roughly a factor of 10.
>
>I'd like to see some studies on this. 
Take a look through the back issues of IEEE Transactions on Software
Engineering. All other things being equal, the number of bugs is generally
directly proportional to the number of source lines. 

>...  C is basically a PDP-11 assembler in a fancy suit, and brings
>with it all of the screw-up possibilities that you get in real assembler.
Where does this strange idea come from? The newest trends in C compilers are
to very fussy type-checking (which is where such things as function
prototypes originate). Admittedly, C compilers can't detect subscript range
violations, but just about all type errors can be detected by some of the
better compilers, or by lint.

>...  C zealots usually
>deny that there exist any applications for which C is a poor fit.
I'm certainly not a C zealot, but I can't think of *any* application for
which C is a poor choice as a language but assembler is a good one. Of
course, that does not mean that a particular C compiler will give code of
adequate efficiency.

>Furthermore, C is more difficult to debug than assembler, because (like
>all other high-level languages) it is distanced from the machine. 
Well, dbx certainly reduces that distance. On the other hand, I know that I
write C programs with a lot fewer errors than my assembler programs, and
therefore my C programs don't make as many trips to the debugger.
Mind you, I use lint a lot on UNIX systems, and the C compiler I use on my
micro (Mark Williams C for the Atari ST) does a very good job of
type-checking.

Doug goes on to remark that C programmers just switched from Basic. Indeed,
there are many incompetent C programmers, just as there are many incompetent
assembler programmers (many of the latter are engineering graduates who had
just *one* programming course). Has nothing much to do with anything, as far
as I can see.

Doug, if you want to program in assembler, then by all means do so. But
please don't attack C because it isn't assembler. I agree that the quality
of much C code is poor; but if you care about this matter, are you out there
running structured programming courses for these people? 

-----
Vincent Manis                {seismo,uw-beaver}!ubc-vision!ubc-cs!manis
Dept. of Computer Science    manis@cs.ubc.cdn
Univ. of British Columbia    manis%ubc.csnet@csnet-relay.arpa  
Vancouver, B.C. V6T 1W5      manis@ubc.csnet
(604) 228-6770 or 228-3061

"Long live the ideals of Marxism-Lennonism! May the thoughts of Groucho
 and John guide us in word, thought, and deed!"