marick@m.cs.uiuc.edu (02/28/90)
The flame fest about languages and errors has come up again. Usually, it gets nowhere. Part of the reason is that people don't think about what they mean by "error". ====================== There are two assertions in Bill Wolfe's message: 1. The C community releases an unacceptable number of errors. 2. The C language is at least partly the *cause* of those errors. The second point is disputed by the counterflamers, usually with "Languages don't kill; people kill" arguments. Both sides are off the track. "Errors" is too broad a notion for this discussion. Errors come in different categories -- there are off-by-one errors, storage leaks, wrong identifier used, etc. etc. Different software products will have different distributions of errors. In at least some cases, language used will be *correlated* with those distributions. For example, you don't see storage leaks in Lisp. A better question than "does C cause more errors than Ada?" is "what are the typical distributions of errors in projects using C and Ada?" It may be that they're the same. In that case, we can drop the issue -- other factors are so much more important that argument is pointless. More likely (I suspect) is that there will be some correlations. C and Ada will be associated with different error distributions, and enough "cross-cultural data" will bring these out, in the same way that anthropologists *do* sometimes find out universal facts about humankind. This wouldn't end the C vs. Ada arguments, of course, since there are still many other factors (productivity, cost of compilers, efficiency, training and so on) to consider. But it would add a tiny increment of evidence to the argument. Further, if we knew what errors were correlated with a particular language, we could use extra-language techniques to help prevent or detect those errors. In a year and a half, I hope to have data on errors in Ada and C as a part of my "error hackers" project. I'll let you know. References to similar studies appreciated. The first assertion (about communities and errors) may also be true. Enough C/UNIX programmers have a similar enough way of doing things that saying they're a community makes some sense. But saying that this community makes too many errors is shallow -- you have to ask what else they make, and you have to ask what *kinds* of errors they make. I've been involved in enough process-improvement efforts to know that it's not as simple as shoving a fire hose in one ear and pumping in "software engineering concepts". It's ever so easy to harm the good while preventing the bad. People will surprise you. Brian Marick Motorola @ University of Illinois Email: marick@cs.uiuc.edu, uiucdcs!marick
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/01/90)
From marick@m.cs.uiuc.edu: > There are two assertions in Bill Wolfe's message: > 1. The C community releases an unacceptable number of errors. > 2. The C language is at least partly the *cause* of those errors. 3. Many members of the C community exhibit an unprofessional and irresponsible attitude regarding defect control and especially defect prevention. 4. Those members of the C community who ARE responsible professionals are apparently not taking significant actions to raise the level of software engineering professionalism within the C community. The unsafe constructs within C are themselves sufficient evidence to conclude that the C community, by choosing to use a language which has many highly unsafe constructs and an almost total disregard for error prevention, does not hold error prevention in sufficiently high regard; the failure of a password security system because no boundary checks were done on the length of the password (whereupon the intruder purposely supplied a double-length password and thereby ensured that the left and right sections of the password-validating data structure were compatible), and similar cases demonstrate that the C language poses a serious obstacle to the development of defect-minimal software. For the cost of simply the recent national AT&T crash, I'd be willing to conjecture that all of AT&T's software developers could have been trained in software engineering concepts and the Ada language, and supplied with Ada compilers as well. The comments found in the Unix man pages I cited have been there for at least a decade, apparently going unchallenged by the rest of the C community. This is despite the fact that the growth of C has been widely attributed to the Unix operating system being given away to so many universities -- if this attribution is correct, then Unix is also responsible for helping to create the widespread attitude within the C community that defects are to be treated casually. It is entirely true that other language communities (BASIC, COBOL, etc.) have problems along these lines which are arguably worse than those which are clearly associated with the C community. On the other hand, there are other language communities which are doing a considerably better job of spreading software engineering concepts and providing linguistic support for their application (Ada, Eiffel, etc.). The challenge for the C community is to join the language communities which are doing a good job in these respects, as opposed to holding its existing reputation as a community which contains an extremely high percentage of those who regard themselves as hackers, and whose products repeatedly make national headlines with their spectacular failures. Since C is a language which provides little or no support for defect prevention, one would expect that the C community would naturally compensate by being extremely careful about always applying the very best software engineering practices. Unfortunately, I don't think even the most dedicated C-backers would attempt to claim that this is presently the case. Bill Wolfe, wtwolfe@hubcap.clemson.edu
ekrell@ulysses.att.com (Eduardo Krell) (03/02/90)
In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > For the cost of simply > the recent national AT&T crash, I'd be willing to conjecture that all of > AT&T's software developers could have been trained in software engineering > concepts and the Ada language, and supplied with Ada compilers as well. And what makes you think the network wouldn't have crashed if the software had been written in Ada (you seem to imply this)? Do you know the details of the cause of the crash?. You're just speculating that it was related to the "unsafe" nature of C. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
peter@ficc.uu.net (Peter da Silva) (03/02/90)
In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Many members of the C community exhibit an unprofessional and > irresponsible attitude regarding defect control and especially > defect prevention. Many members of the programming community as a whole exhibit an unprofessional and irresponsible attitude regarding defect control and expecially defect prevention. C happens to be the most popular language on a wide range of hardware, by the chance that it happens to be well adapted to writing reasonably portable and reasonably efficient programs, without being particularly hard to implement or having particularly many functional shortfalls. Most other system programming languages are either harder to implement (such as ADA), do not fit well into the normal program linking model (such as Modula), or are simply inadequate without nonstandard extensions (most dialects of Pascal). Thus, simply by statistics one could predict that a large number of programs written in C are likely to contain major bugs. There are a large number of programs written in C, period. Would you care to address the confusing and dangerous deficiencies in the ADA language: operator overloading and the use of rendezvous for interprocess communication, for example? Have you read C. A. R. Hoare's Turing Award lecture, "The Emperor's New Clothes"? -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
mcilree@mrsvr.UUCP (Robert McIlree) (03/02/90)
From article <12643@ulysses.att.com>, by ekrell@ulysses.att.com (Eduardo Krell): > In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >> For the cost of simply >> the recent national AT&T crash, I'd be willing to conjecture that all of >> AT&T's software developers could have been trained in software engineering >> concepts and the Ada language, and supplied with Ada compilers as well. > > And what makes you think the network wouldn't have crashed if the software > had been written in Ada (you seem to imply this)? Do you know the details > of the cause of the crash?. You're just speculating that it was related > to the "unsafe" nature of C. Let me add something to Eduardo's comments: The vast majority, if not all, of AT&T's developers *are* trained in software engineering concepts in-house. I know. I used to work at Bell Labs. I learned more about software engineering, methodologies, and development lifecycles from that environment than in any other place I've worked, before or since. At a minimum, that training was far better than what it appears you have learned at Duke (bastion of CS that it is), Mr. Wolfe - if simply by judging the quality of the school from your postings of absolute conjecture and crap. Oh, is the above a little unfair? Well, so is your indictment of C without: a) facts and b) experience. Programming languages are not the root of all evil. Failures are also linked to inadequate analysis, lack of testing, poor development environments, and documentation problems, to name a few. I'll reiterate to you that systems are not, and never are 100% reliable. The AT&T crash was bound to happen sooner or later, but not because the software was coded in C. Things like software complexity and network topology issues come to mind immediately, with nothing at all to do with language specificity. Perhaps you can take the time to put down the Ada manual and learn something about these topics, because the lack of depth in your pronouncements is showing. Unfortunately, very little of the drivel you have posted in these forums touch on non-coding parts of the development lifecycle. You, for one reason or another, simply ignore them and keep thumping your Ada bible like some evangelical idiot. Ignorance of those topics doesn't make you a software engineer. At best, it makes you a coder. And coders, Mr. Wolfe, are a dime-a-dozen. So are religous wars on which programming languages are "the best." If you're going to indict the software engineering community for your percieved attrocities and ignorace, perhaps you could start at the top - like in requirements and management issues, which is where the majority of the problems start. Blasting Joe-C-Programmer for the world's ills is just so much hot air - which is to be expected from you, I'd reckon. Bob McIlree
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/02/90)
From ekrell@ulysses.att.com (Eduardo Krell): > And what makes you think the network wouldn't have crashed if the software > had been written in Ada (you seem to imply this)? Do you know the details > of the cause of the crash?. The crash apparently was caused by a programmer who used a "break" within an if (which itself was within a switch) for the purpose of exiting the if; the real result was to exit the switch instead. If C provided a case statement rather than a switch..break system, then the error would most likely have been prevented. See the recent discussion of this topic in comp.lang.c. Bill Wolfe, wtwolfe@hubcap.clemson.edu
stevee@ism780c.isc.com (Steve Ellingson) (03/02/90)
C is a language for consenting adults, Pascal is a language for naughty children, and Ada is a language for criminals! Steve
mitchell@community-chest.uucp (George Mitchell) (03/02/90)
In article <2272@mrsvr.UUCP> mcilree@mrsvr.UUCP (Robert McIlree) writes:
`From article <12643@ulysses.att.com>, by ekrell@ulysses.att.com
`(Eduardo Krell):
`>
`> And what makes you think the network wouldn't have crashed if the software
`> had been written in Ada (you seem to imply this)? Do you know the details
`> of the cause of the crash?. You're just speculating that it was related
^^^^^^^^^^^
`> to the "unsafe" nature of C.
`
`Oh, is the above a little unfair? Well, so is your indictment of C
`without: a) facts and b) experience.
^^^^^^^^^^^^^^^^^
Let's have the facts, not additional speculation and ad hominem attacks.
The putative source of the problem does indeed appear to be language
*related* (not language caused). If internal sources have evidence to
show that the design and implementation of C were not factors in this,
let's hear from them. It is not necessary to show that other language
designs and implementations are imperfect or that the development
practices of any group is better/worse than another.
--
/s/ George vmail: 703/883-6029
email: gmitchel@mitre.org [alt: mitchell@community-chest.mitre.org]
snail: GB Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102drh@romeo.cs.duke.edu (D. Richard Hipp) (03/02/90)
In article <2272@mrsvr.UUCP> mcilree@mrsvr.UUCP (Robert McIlree) writes: >From article <12643@ulysses.att.com>, by ekrell@ulysses.att.com (Eduardo Krell): >> In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >... >... At a minimum, that training was far better than what >it appears you have learned at Duke (bastion of CS that it is), Mr. >Wolfe - if simply by judging the quality of the school from your postings >of absolute conjecture and crap. Please, please, folks... clemson != Duke
crm@romeo.cs.duke.edu (Charlie Martin) (03/02/90)
In article <2272@mrsvr.UUCP> mcilree@mrsvr.UUCP (Robert McIlree) writes: >From article <12643@ulysses.att.com>, by ekrell@ulysses.att.com (Eduardo Krell): >before or since. >....At a minimum, that training was far better than what >it appears you have learned at Duke (bastion of CS that it is), Mr. ^^^^ >Wolfe - if simply by judging the quality of the school from your postings >of absolute conjecture and crap. > 'ere now! Should we judge the quality of your postings from the fact that you can't read header lines, and/or think Clemson == Duke? There are a lot of basketball fans who would argue with that. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
ekrell@ulysses.att.com (Eduardo Krell) (03/03/90)
In article <8201@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > The crash apparently was caused by a programmer who used a "break" > within an if (which itself was within a switch) for the purpose of > exiting the if; the real result was to exit the switch instead. From what I've heard, the problem was with a "break" statement followed by dead code (which was critical). If that's the case, you can blame that particular C compiler for not issuing a warning (some of them do) or the testers for not exercising the code, but you can't blame C because the same thing would have hapenned in, say, Ada. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
runyan@hpcuhc.HP.COM (Mark Runyan) (03/03/90)
>/ billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe) >From marick@m.cs.uiuc.edu: >> There are two assertions in Bill Wolfe's message: >> 1. The C community releases an unacceptable number of errors. >> 2. The C language is at least partly the *cause* of those errors. > 3. Many members of the C community exhibit an unprofessional and > irresponsible attitude regarding defect control and especially > defect prevention. > 4. Those members of the C community who ARE responsible professionals > are apparently not taking significant actions to raise the level > of software engineering professionalism within the C community. As a memember of your so-called 'C community', I find your postings offensive and nearly meaningless. The only point that comes from it that I agree with is that C programmers (or any programmer) should be learning more about software engineering, especially the new developments. > The unsafe constructs within C are themselves sufficient evidence to > conclude that the C community, by choosing to use a language which has > many highly unsafe constructs and an almost total disregard for error > prevention, does not hold error prevention in sufficiently high regard; Those very constructs which you despise are what allows C to be a useful language. The fact that some engineers use the poorly does not mean that C is any more deadly than driving a car or riding a motorcycle. In my opinion, which may seem cavilar or unprofessional to you, Mr Wolfe, your message could have been put in terms that wouldn't insult a large number of engineers who have done considerable work to reduce the number of defects in code around the world (or even to ensure that no defects are ever released). Perhaps you could have convinced more people that your point of view was reasonable if you hadn't been so insulting to begin with. If you are going to continue to try to 'improve' the 'C community', I wish you luck, for you are going to need it if you continue to use your current tactics. Mark Runyan A C programmer and proud of it. {runyan@hpda.hp.com 408)447-6676}
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (03/03/90)
From article <8201@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > The crash apparently was caused by a programmer who used a "break" > within an if (which itself was within a switch) for the purpose of > exiting the if; the real result was to exit the switch instead. If > C provided a case statement rather than a switch..break system, then > the error would most likely have been prevented. The problem was obviously the ignorance of the programmer. Blaming the fruits of that ignorance on the language in which he/she was programming is a comperable error. The syntax of the switch construct and the functionality of break have been well defined for well over a decade. It would be much more constructive, and more appropriate to software-eng, to observe that such a primitive error would have been caught and fixed, before it had a chance to do any damage, if the organization in which the routine was developed observed the practice of code reviews. This might not be a popular answer in some circles, but it is the only competant answer to this problem. Chris Prael
sanders@sanders.austin.ibm.com (Tony Sanders) (03/06/90)
In addition to the multitudinous messages already written on this subject I would like to add a couple thoughts. In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From marick@m.cs.uiuc.edu: >> There are two assertions in Bill Wolfe's message: >> 1. The C community releases an unacceptable number of errors. Bill, please tell us exactly what the error rate is. I assume you must have some stats to back this up (maybe lines/errors?), or are you just making stuff up? >> 2. The C language is at least partly the *cause* of those errors. Nope, programmers that don't have a clue is mostly the cause of those errors (referring to stupid errors that Bill claims were caused by the C language). > 3. Many members of the C community exhibit an unprofessional and > irresponsible attitude regarding defect control and especially > defect prevention. > 4. Those members of the C community who ARE responsible professionals > are apparently not taking significant actions to raise the level > of software engineering professionalism within the C community. On reason you might have this observation is because Joe Smith gets a computer and *Shazam* he's a "real programmer" (CSMAJORS for short). (note: CSMAJORS here only refers to those people who got the CS degree because it pays well, there are of course "real programmers (tm)" that have CS degrees) The current market demand for programmers exceeds the supply of "real programmers (tm)" thereby creating a demand for CSMAJORS. The reason these people exist is because of the demand for people to fill programming jobs. If employers were not willing to pay top dollar for these people as programmers they would not be programmers at all, they would go and get themselves an MBA or whatever they could use to make the most money. > The unsafe constructs within C are themselves sufficient evidence to > conclude that the C community, by choosing to use a language which has > many highly unsafe constructs and an almost total disregard for error > prevention, does not hold error prevention in sufficiently high regard; Bullshivicky! What does the level of handholding a language provides have to do with anything. Making unsupportable claims undermines your argument (again). > as opposed to holding its existing reputation > as a community which contains an extremely high percentage of those who > regard themselves as hackers, and whose products repeatedly make national "regard themselves as hackers" is a key phrase here. You are again talking about the CSMAJORS, and this has nothing to do with the "C-community". This is a problem in any language, there are more CSMAJORS programming in C simply because it is becoming the language of choice (with good reason in my opinion). In the future if you want to flame some group for all the buggy code out there, go talk to the people who hire people who can't program. -- sanders Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders "she was an innocent bystander, it's a democracy" -- Jim Morrison