C Community's Cavalier Attitude On Software Reliability

[Martin Weitzel]

In article <8147 at hubcap.clemson.edu> wtwolfe at hubcap.clemson.edu (Bill Wolfe) writes:
>
> Following are some prime examples of why the C community is thought 
> of by many as having an unprofessional and irresponsible attitude 
> toward software reliability:
>  
[list of citations deleted]

A language with no bugs documented does not necessarily have none.
A language that is not critized for deficiencies, is suspicious not
to be in wide use.

Two years ago I decided to start a project with INFORMIX 4GL.
>From time to time my work went into isolating contained Bugs.
(Because I just was learning myself, it often took some time
to trim down the problem to the smallest failing case, then
to detect that it was not my fault and finally finding some
workaround.) Of course, the bugs were never mentioned in any
manuals and might give some naive user the impression, that
the language was "better" than C. I think within three months
of work I spent at least three weeks with isolating bugs and
looking for workarounds!

The next thing I missed in this language were constants:
You could not do other than writing them explicitly twice,
if you defined an array and had to write a loop to process the
entries later. I think, a language that calls itself "fourth
generation" should have learned from 3rd generation languages!
I had to circumvent this by writing my own preprocessor (with
UNIX m4). The support for structuring a program into multiple
reusable moduls, was far below that of C.

Language constructs seemed somewhat arbitrary defined.
Eg in C, if there is a 'int'-value required, there are
only two situations: It must be a compile-time expression
or it can any expression evaluated on run-time, ranging
from a constant to a complicated expression with indexed
array elements or whatever. Not so in 4GL: Sometimes a
constant and a variable was allowed, sometimes only
a constant or only a variable (yes, there were situations
were a *value* which was used unchanged had to be a
from a variable, not a constant.) Sometimes expressions
were allowed, but on other occasions theese should not
have any array-elements embedded. Again: this language
was called a *fourth* generation language.

Finally, the project was unsuccesfull on the 80286, because
of its limited (segmented) adress space and the tendency of
a 4GL-Program to grow really large in a serious programm, that
had to do a little more than the demo data base that came
with 4GL. I allways lived in the fear, that I could reach the
limits of some resource, because for the fewest of them any
"minimum guarantees" were given! Finally, the 80286 segmentation
and the linker came into way. (With C I could be sure, that
anything as complex as a compiler and the UNIX-Kernel can
be writte in this language.)
>
> It appears that there is a real need to publicize software engineering 
> concepts throughout the C community, both directly through software
> engineering education and indirectly through a redesign of the C language
> to provide greater support for the software engineering process.  If

A C programmer needs more education, training and knowledge as the
average BASIC programmer - but not because the language is worse
in design than others, but because more serious work is done in C.
I don't believe, that any other language with the same broad
spectrum of uses as C, can be designed to be used with less effort
or education. You may take this as my vote, that we need more
specialized languages for certain problem domains, but I think
there is few room for a 'better C'.

At least for INFORMIX 4GL (in the state of design from 1988) I can
say, that a newer language which promissed that you "describe the
solution, not the way to get to the solution" was worse than C
in any aspect, if you tried to use it for non-trivial projects!
(BTW: ESQL/C is much better in this respect, but leads the not
so well educated programmers into all traps and pitfalls you find
in C.)

> these steps are taken, it will hopefully be possible to avoid any further
> destruction of the public's confidence in software reliability.  If not,
> government regulation of the field will probably soon become inevitable.

What kind of regulation are you thinking of? (Don't know,
if I should put a Smiley here or if you forgot one ....)
>
>
> Bill Wolfe, wtwolfe at hubcap.clemson.edu
> 
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83