Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!uwvax!oddjob!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <658@edge.UUCP>
Date: Fri, 17-Apr-87 13:13:19 EST
Article-I.D.: edge.658
Posted: Fri Apr 17 13:13:19 1987
Date-Received: Sun, 19-Apr-87 02:00:54 EST
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 77

I was afraid of this.  I figured I'd get some flak when I wrote:

me > If you are more concerned about efficiency than about portability, then
me > consider this:  There are 4 basic reasons for writing a particular program
me > in C instead of in assembler:
me >  a)  If efficiency is of little consequence -- the program is only going to
me >      be run once or twice;
me >  b)  If portability is important;
me >  c)  If the programmer is ignorant of assembler; or
me >  d)  If the boss wants "BIC lighter" programmers: cheap, disposable, and
me >      easily replaceable.

Comment 1:

> 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.

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.  This is not a black mark against the C language itself,
but rather against the smug arrogance of the scads of C programmers who
believe that C is so inherently readable and maintainable that comments are
superfluous.

Comment 2:

> You forgot
> 
>    e)  Reducing the opportunity for bugs by roughly a factor of 10.

I'd like to see some studies on this.  I'd believe it for languages like
FORTRAN, COBOL, and Ada which prevent the programmer from making really
stupid mistakes like not being able to tell a string literal from an
array of characters, or arithmetic overflow/divide-by-zero/floating point
overflow/underflow, or the infamous "if (x=y)" type of stuff that C
allows.  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.

C is often used in applications where it is a poor fit, and this causes
lots of room for screw-ups as the programmer tries to work around the
limitations of the language.  Device drivers in particular.  (Isn't
"portable device driver" almost an oxymoron?).  All languages, including
assembler, are often used in applications where they are a poor fit, with
the result that the code tends to be excessively buggy.  C zealots usually
deny that there exist any applications for which C is a poor fit.

Furthermore, C is more difficult to debug than assembler, because (like
all other high-level languages) it is distanced from the machine.  To
debug C you either need to know assembler, and to debug it at the assembler
level, or you need a symbolic debugger.  A lot of systems don't *have*
symbolic debuggers, or the ones they have are not full-functioned.  And
I haven't seen one yet that will allow a C programmer to make a patch to
the code *in C*.

And finally, <<<Break out the fireproof suits!>>>  all of the above was
based on "programmers of equal competency".  But consider that point (d)
above virtually guarantees that the ever-increasing pool of marginally
competent programmers (you know the ones, "I got me a PeeCee and learnt
meself how to program in Basic and C") will be hired by penny-pinching
companies to program in C.

I'm not saying that you personally (whoever you may be) are marginally
competent.  I *am* saying that if you restrict yourself to the C programming
job market, you will be competing with a lot of bozos who are willing to work
for peanuts (hey, it beats flipping burgers for a living!).  And in return for
this limited pay, you will get to maintain the programs those bozos wrote.  If
you don't like it, the boss can dump you and hire another bozo; he's got 2
dozen resumes on file.  *That's* what I mean about BIC lighter programmers.

-- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona