Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.lang.c
Subject: Re: C vs assembler, or, Here We Go Again
Message-ID: <6361@mimsy.UUCP>
Date: Sat, 18-Apr-87 22:40:10 EST
Article-I.D.: mimsy.6361
Posted: Sat Apr 18 22:40:10 1987
Date-Received: Sun, 19-Apr-87 11:45:29 EST
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 94

In article <658@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes:
>A C program is no more readable to a C programmer than an assembler
>program is to an assembler programmer.  Ditto for maintainability.

Probably true; yet, as has been pointed out, `understandability'
appears to be a linear function of size as well, and equivalent C
and assembly programs tend to differ in size.  Usually the C code
is substantially shorter.  To put it another way, the C program
somehow represents a longer, and therefore less maintainable,
assembly program.

>I'd like to see some studies on this.

I cannot say why I think this, but I think the studies were on
FORTRAN and Algol.

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

(In C, a string literal *is* an array of characters; there is no point
in trying to tell the two apart.  In my experience, this has not been
a problem.)

>or arithmetic overflow/divide-by-zero/floating point overflow/underflow,

FORTRAN does not protect programmers from these:

	PROGRAM FOO
	REAL A, B
	A = 1E+35
	B = 1E-35
	A = A / B
	STOP
	END

breaks quite nicely.  (I have used neither COBOL nor Ada [sigh of
relief :-) ], and cannot say what they do or do not provide.)

>or the infamous "if (x=y)" type of stuff that C allows.

(Suitably smart versions of lint complain about these.)

>C is often used in applications where it is a poor fit,

True.

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

Both of these assertions are ludicrous.  C is no more difficult to
debug than any other language.  Certainly, symbolic debuggers help.
I would not want to work without one: not in C, not in assembly.
If you mean to say that symbolic assembly debuggers are more common
than symbolic C debuggers, well, perhaps so.  But I will say that
any C programmer should spot the bug in the following immediately:

	f()
	{
		int a[10], i;

		for (i = 0; i <= 10; i++)
			a[i] = i;
		...
	}

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

I dare say you have not looked hard enough.  They are rare, but (if
you will accept C interpreters) they do exist.

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

But I can often, after a moment of search, point into the middle
of a routine and say `there is the bug': and this distinguishes me
from your BIC lighter programmer.  The smart boss recognises this,
and pays more to or otherwise compensates the competent programmer.
Of course, this same competent programmer is more than likely fluent
in many computer languages, or able to pick them up quickly, and
hence need not restrict {him, her, it}self to C.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu