Xref: utzoo comp.lang.c:26458 comp.software-eng:2994 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!arcturus!evil From: evil@arcturus.UUCP (Wade Guthrie) Newsgroups: comp.lang.c,comp.software-eng Subject: Re: C Community's Cavalier Attitude On Software Reliability Keywords: Unprofessional Irresponsible Message-ID: <7351@arcturus> Date: 1 Mar 90 19:07:24 GMT References: <8147@hubcap.clemson.edu> Organization: Rockwell International, Anaheim, CA Lines: 87 wtwolfe@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: > DAB(!1) [...] FILE(1) [...] JOBS(3J) [...] PARSEDATE(3) [...] > CTAGS(1) [...] EMACS(1) [...] TC(1) [...] UNITS(1) [...] BBEMACS(1) #define FLAME TRUE What do THESE have to do with the C community? I can tell you that I feel myself a member of that community and have NEVER programmed one of these. Moreover, one can put things in "local language" without being irresponsible or cavalier (or are you against Vatican II as well?). Messages such as: > There is a mysterious bug causing occasional core dumps [...] > It often makes mistakes [...] > The grammar is incomplete and always will be [...] > The value of 'tan' for arguments greater than about 2**31 is garbage. > if you have two Pascal procedures in different blocks > with the same name, you lose. and even: > Not bloody likely. > Don't base your financial plans on the currency conversions. are honest indications of where problems may exist, and they do so in language that can be enjoyed by the person reading the manual. Just because the language is not on a par with "Segmentation fault, core dumped", or "Error R2702", or the all-too-famous "Syntax error" doesn't mean that people don't care that the errors are there or that they didn't try to fix them -- it means that the error is recognized and it means that the people writing the manuals are human. It is okay to smile while you are writing your code; enjoyment of ones work allows him to produce more work of a higher quality. > [...] and the fact that C > software seems to erode public confidence in software reliability on a > regular basis (Nationwide Computer Network Infected By Worm; National > Telecommunications System Crashes), The fact that someone can break software does not mean that it is unreliable. Can someone devoting lots of effort break YOUR code? > When is the C community going to clean up its act??? G.M.A.B. (give me a break) > It appears that there is a real need to publicize software engineering > concepts throughout the C community, Throughout ALL software engineering communities. Around here, the Fortran programmers need it a lot more than the C programmers -- not that the C programmers don't. > both directly through software > engineering education and indirectly through a redesign of the C language > to provide greater support for the software engineering process. The whole CONCEPT behind C is to give the programmer a significant amount of power. Power which can be used to do good things or bad. C is a language that does not coddle the programmer; if used with care, C can allow a programmer to do great things. If you believe that power corrupts, however, feel free to use Ada. > [...] If not, > government regulation of the field will probably soon become inevitable. AAAAaaaaahhhhhHHHrrrRRRrrgggggHHHHHH! Government regulation of the private sector? Good God, man; don't you study your history? How about Adam Smith and the invisible hand? If C software is not reliable, let the consumer decide. Letting the government in, well that's just stupid (unless you're talking about Government contracts -- then retract all this stuff). #undef FLAME -- Wade Guthrie (evil@arcturus.UUCP) Rockwell International; Anaheim, CA; My opinions, not my employer's. "All right, so I'm panicking, what else is there to do?"