Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.sw.components
Subject: Re: Are "production" programming languages are dinosaurs?
Summary: cheap shots at C
Message-ID: <428@e-street.Morgan.COM>
Date: 6 Oct 89 22:42:54 GMT
References: <929@scaup.cl.cam.ac.uk> <30@venice.SEDD.TRW.COM> <16160@vail.ICO.ISC.COM>
Organization: Morgan Stanley & Co. NY, NY
Lines: 66

> > 
> >   C is mature?  There isn't even a standard for it yet!...
> 
> This is a cheap shot.  C has been developed in the natural sequence, namely
> "try it first, then standardize it."  The fact that Ada was standardized
> before there was even an honest working compiler for it--let alone any
> useful experience with the language--is such a massive act of monstrous
> stupidity that even now, years later, I (and most other programming-lang-
> uage folks) have trouble believing it was done that way.
> 
>

It is impossible to take a cheap shot at the lack of standardization of C.

C has been developed along the lines of; get something working and lists the
bugs as features later. When it turns out you have to turn your head inside
out to cope with the goo that passes for 'traditional' C source, you excuse
the miscreants because when they were growing up, that piece of code could
only be done by machine specific finesse, and now they write all their goo
likewise so the awful parts don't stick out so much.

C is the only widely used compiled language for which a program can (in 
principle) be constructed so that:

1. The program is syntactically correct.

2. For every input, the program eventually halts.

3. It is not possible to determine from the sources what logical relation
the input bears to the output. 

(In the jargon of computer science, rules for proving partial correctness
cannot be given for all of the C language. The commonly used unbound pointer
is the culprit here.)

Let's not get into the stupid issues, (what order should bytes appear in a word
in), and the glaring unreadabilities, (int* a,b,c; often written, always a
miscue!), and the downright ugliness of this woeful UNIX stepchild. Let's
talk about what C does to otherwise good programmers.


I am the first to admit that working in an ad-hoc language corrupts your
ability to program effective readable code. I was once a very sharp Pascal
programmer (on the grounds that ALGOL 68 was never really coming). After
about one year of exposure to the insidious APL language and first went
my FORTRAN skills (the least structured are the first to go) but recently
I have been stuck for syntax of case statements, and other simple Pascal
constructs, which do not need to be remembered, but can be reconstructed
from the principles of the language. I'm starting to remember little tricks
and devices as opposed to reasoning about code constructs. Having been 
exposed to both APL and C, I can definitely state that the fewer letters
in the language name, the more ad hoc the syntax is.

There are no cheap shots at C; it deserves all the flames it gets, and much
more.

If C is a mature language, let's ask: "Does this mean we won't have to put
up with it much longer?"

Oh well, wishful thinking, I guess.

Later,
Andrew Mullhaupt

Disclaimer: Any opinions expressed here are entirely my own. Often I wished
more people would admit to themselves what a hodgepodge C is.