* problems/risks due to programming language, stories requested
@ 1990-02-20 22:28 Gerald Baumgartner
1990-02-21 16:49 ` Richard A Hammond
` (3 more replies)
0 siblings, 4 replies; 60+ messages in thread
From: Gerald Baumgartner @ 1990-02-20 22:28 UTC (permalink / raw)
For a research project I am collecting information about the risk of
choosing the wrong programming language. In particular I am looking
for problems that could have been avoided if another (a better)
programming language would have been used.
I know of these three such stories:
1. There is the famous story that a Mariner probe got lost
because of the Fortran statement `DO 3 I = 1.3' (1.3 instead
of 1,3) (see Peter Neumann: A Few Old War Stories Reappear.
ACM SIGSOFT 11(5), Oct. 1986, pp. 16-18). It is a nice story
but, as far as I know, NASA used Jovial at that time and not
Fortran.
2. One of the security holes the Internet Worm took advantage of
was in fingerd (the finger deamon). The deamon uses the gets
routine for input. This routine, written in C, reads input
without checking for bounds on the buffer involved. By
overrunning the buffer, the worm rewrote the stack frame (see
Eugene H. Spafford: Crisis and Aftermath. Communications of
the ACM 32(6), June 1989).
There would be no security hole in the finger daemon if a
programming language would have been used for the I/O
routines, where the compiler takes care of boundary checks for
arrays. Pascal doesn't work since variable length strings are
needed, but Ada would be fine. A language a la ML, where these
checks are done at compile time, would be even better.
3. The AT&T breakdown a month ago was caused by a break statement
in C. See the following mail (multiple forwarding headers deleted):
Subject: AT&T software problem
Subject: Cautionary note on C programming...AT&T learns from experience
>From: kent@wsl.dec.com
Subj: I've always thought C looked like line noise.
Subj: the bug
Subj: AT&T's bug, for you C users out there...
Subj: I C what they mean!
Subj: "c" considered dangerous to telephones
Subj: Be careful from where you break! (else no long distance calls will make it thru...)
Subj: C switch breaks AT&T switches!
Subj: your "c users" list might appreciate this....
I received the following on AT&T's famous bug (and have deleted multiple
forwarding headers):
| | Subject: AT&T Bug
| | Date: Fri Jan 19 12:18:33 1990
| |
| | This is the bug that cause the AT&T breakdown
| | the other day (no, it wasn't an MCI virus):
| |
| | In the switching software (written in C), there was a long
| | "do . . . while" construct, which contained
| | a "switch" statement, which contained
| | an "if" clause, which contained a
| | "break," which was intended for
| | the "if" clause, but instead broke from
| | the "switch" statement.
| |
Again it looks like this bug wouldn't have occurred in another
programming language.
You C what I mean? Do you know other stories like these, if possible
with references? I don't want to praise Ada or pick at C and Fortran;
I am looking for any story where a proveably inappropriate/insecure
programming language has been used.
Gerald Baumgartner gb@cs.purdue.edu ...!{decwrl,gatech,ucbvax}!purdue!gb
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-20 22:28 problems/risks due to programming language, stories requested Gerald Baumgartner @ 1990-02-21 16:49 ` Richard A Hammond 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 1990-02-22 0:25 ` problems/risks due to programming language, stories requested David Kassover 1990-02-23 18:11 ` Thomas Vachuska ` (2 subsequent siblings) 3 siblings, 2 replies; 60+ messages in thread From: Richard A Hammond @ 1990-02-21 16:49 UTC (permalink / raw) In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: >For a research project I am collecting information about the risk of >choosing the wrong programming language. In particular I am looking >for problems that could have been avoided if another (a better) >programming language would have been used. >I know of these three such stories: ... > 3. The AT&T breakdown a month ago was caused by a break statement > in C. See the following mail (multiple forwarding headers deleted): >| | This is the bug that cause the AT&T breakdown >| | the other day (no, it wasn't an MCI virus): >| | >| | In the switching software (written in C), there was a long >| | "do . . . while" construct, which contained >| | a "switch" statement, which contained >| | an "if" clause, which contained a >| | "break," which was intended for >| | the "if" clause, but instead broke from >| | the "switch" statement. >| | > > Again it looks like this bug wouldn't have occurred in another > programming language. What other programming language? Only one without any GOTO or restricted GOTO (e.g. exit, break, ...). This leaves out Ada!!!!!! Similar bug in Ada: (Cut down for posting, but gives the flavor) procedure test is MAX : constant := 10; type t is array(positive range 1 .. MAX) of boolean; NEW_ITEMS : t; begin for N in 1 .. MAX loop case ... when ... => if NEW_ITEMS(N) = FALSE then -- some other useful work gets done here exit; -- exits loop, not if! end if; when ... => end case; end loop; end test; So, in the AT&T case using Ada we would have exited both the switch and the loop rather than just the switch. Hardly an improvement! More generally, I find it distressing that the advocates of Ada are failing to distinguish between language independent features and language dependent features in assigning credit for software improvements. In my limited experience the cases where Ada is introduced into a programming environment also introduce lots of other good software engineering practices. For example, lots of people I know who program in C don't use LINT. I view it as a deficiency of management and not of the language that they don't use available tools. I bring this up because Ada isn't the last language ever to be designed and we should be willing to learn what could be used in future languages. Rich Hammond ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-21 16:49 ` Richard A Hammond @ 1990-02-21 20:15 ` William Thomas Wolfe, 2847 1990-02-21 22:49 ` Richard A Hammond ` (4 more replies) 1990-02-22 0:25 ` problems/risks due to programming language, stories requested David Kassover 1 sibling, 5 replies; 60+ messages in thread From: William Thomas Wolfe, 2847 @ 1990-02-21 20:15 UTC (permalink / raw) From hammondr@sunroof.crd.ge.com (Richard A Hammond): >> 3. The AT&T breakdown a month ago was caused by a break statement >> in C. See the following mail (multiple forwarding headers deleted): > >>| | In the switching software (written in C), there was a long >>| | "do . . . while" construct, which contained >>| | a "switch" statement, which contained >>| | an "if" clause, which contained a >>| | "break," which was intended for >>| | the "if" clause, but instead broke from >>| | the "switch" statement. >>| | >> >> Again it looks like this bug wouldn't have occurred in another >> programming language. % % What other programming language? Only one without any GOTO or restricted % GOTO (e.g. exit, break, ...). This leaves out Ada!!!!!! % % [...] for N in 1 .. MAX loop % case ... % when ... => % if NEW_ITEMS(N) = FALSE then % -- some other useful work gets done here % exit; -- exits loop, not if! % end if; % when ... => % [...] % So, in the AT&T case using Ada we would have exited both the switch and the % loop rather than just the switch. Hardly an improvement! This is not a valid analogy. In C, the case statement *requires* the use of a restricted GOTO in order to accomplish "normal" processing; at the end of the section of code processing a given case, one must use a restricted GOTO in order to prevent C from sending the flow of control straight into the section of code which was intended to process the NEXT case. In other words, C requires the programmer to use a dangerous construct on a routine basis. With the if construct in C, the default is to exit the if construct automatically, as opposed to continuing on to execute the section of code associated with the else part. Thus, we have an inconsistency in C's design: with one flow-of-control construct (the switch), it is necessary to use a dangerous GOTO to achieve normal processing, whereas with a similar flow-of-control construct (the if-else), the default is reversed. Given such a language design, it should not surprise anyone that programmers become confused, particularly when the constructs are being used together. Ada, on the other hand, is consistent: in both the if and case statements, the default is to exit the construct once the code associated with the specified situation has been executed. Ada also provides the exit statement, a restricted GOTO which permits a loop to be exited early, but this construct is not used (as is C's break) on a routine basis. > In my limited experience the cases where Ada is introduced into a > programming environment also introduce lots of other good software > engineering practices. For example, lots of people I know who > program in C don't use LINT. I view it as a deficiency of management > and not of the language that they don't use available tools. This is certainly true; Brooks and others have noted that the good software engineering practices which are routinely introduced in conjunction with the Ada language are responsible for more of the resulting improvements than the fact that the Ada language was introduced. However, we cannot disregard that fact that Ada was specifically designed to provide maximal support for the software engineering process. C, on the other hand, was designed to provide maximal support for the compilation process. Since compilers and the CPU power required to operate them come far more cheaply than programmers, and especially in view of the fact that better error prevention is worth much more than faster compilation, it would seem that the tradeoff made by Ada is certainly the one to be preferred. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 @ 1990-02-21 22:49 ` Richard A Hammond 1990-02-21 23:14 ` John F Nixon ` (3 subsequent siblings) 4 siblings, 0 replies; 60+ messages in thread From: Richard A Hammond @ 1990-02-21 22:49 UTC (permalink / raw) In article <8103@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: ... > This is not a valid analogy. In C, the case statement *requires* the > use of a restricted GOTO in order to accomplish "normal" processing; ... > With the if construct in C, the default is to exit the if construct > automatically, as opposed to continuing on to execute the section of > code associated with the else part. Thus, we have an inconsistency > in C's design: with one flow-of-control construct (the switch), it is > necessary to use a dangerous GOTO to achieve normal processing, whereas > with a similar flow-of-control construct (the if-else), the default is > reversed. Given such a language design, it should not surprise anyone > that programmers become confused, particularly when the constructs are > being used together. Bull!!! I've seen lots of errors in C code, and this is the first time I've seen or heard of such an error. If it really was all that confusing, I'd expect to have seen it much more frequently. In fact, the structures are quite different, since a case in a switch has a sequence of statements without any additional brackets, whereas an if statement controls only a single statement, so it is usually followed by "{" and "}" to bracket multiple statements. I expect it was an editing error that pulled the "break" inside the if, rather than leaving it at the end of the case. If that is true, then the same error could be made in Ada, it certainly is not PREVENTED in Ada. As the anti-nuclear protesters will gladly explain, 0 risk and a reduced risk are not the same!!!! > ... C, on the other hand, was designed to provide > maximal support for the compilation process. Where did you get this idea? I believe a better statement is found in AT&T Bell Laboratories Technical Journal, Vol 63, No 8, Part 2, pg 1686, Oct. 1984 "A major trend in the development of C is toward stricter type checking, along the lines of languages like Pascal. However, in accordance with what has been called the "spirit" of C (meaning a model of computation that is close to that of the underlying hardware), many areas of the language specification deliberately remain permissive." This does not imply that it was meant to support the compilation process, but rather, that without huge runtime libraries I could run something through a C compiler and execute it on a bare machine. Rich Hammond ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 1990-02-21 22:49 ` Richard A Hammond @ 1990-02-21 23:14 ` John F Nixon 1990-02-22 5:39 ` Scott MacHaffie ` (2 subsequent siblings) 4 siblings, 0 replies; 60+ messages in thread From: John F Nixon @ 1990-02-21 23:14 UTC (permalink / raw) billwolf (William Thomas Wolfe, 2847 ) writes: >From hammondr@sunroof.crd.ge.com (Richard A Hammond): >> So, in the AT&T case using Ada we would have exited both the switch and the >> loop rather than just the switch. Hardly an improvement! > This is not a valid analogy. In C, the case statement *requires* the > use of a restricted GOTO in order to accomplish "normal" processing; But we aren't talking about using the "break" in this sense, we are talking about using the "break" to exit an "if", something which isn't C. > In other words, C requires use [of] a dangerous construct on a routine basis. Just as Ada requires the use of "exit" to leave the "loop" construct; unless you use Ada'a "goto"... > With the if construct in C, the default is to exit the if construct > automatically, as opposed to continuing on to execute the section of > code associated with the else part. Thus, we have an inconsistency > in C's design: with one flow-of-control construct... use(s) dangerous > GOTO [normally] whereas a similar flow-of-control construct... default is > reversed. Given such a language design, it should not surprise anyone > that programmers become confused, particularly when the constructs are > being used together. This argument applies equally to Ada's "loop" construct versus Ada's "if" construct. > Ada, on the other hand, is consistent: in both the if and case statements, Ignoring the example presented (Ada's loop and exit). > the default is to exit the construct once the code associated with the > specified situation has been executed. Ada also provides the exit > statement, a restricted GOTO which permits a loop to be exited early, > but this construct is not used (as is C's break) on a routine basis. Unless one uses the "loop" statement on a routine basis. Bill may not, but what if I do? And if the reversed sense is such a bad example of program language design, then Ada is an example of bad program language design. I'm not trying to tag Ada, or praise C, but simply to make the point that this case is *not* an example of error a language such as C or Ada detects. Both programs are legal, both will compile, both are wrong. Neither C nor Ada are free of flaws. However, C has not made claims such as the one which follows: > However, we cannot disregard that fact that Ada was > specifically designed to provide maximal support for the software > engineering process. I agree. However, Ada doesn't pass the test in this case. It is possible (nay, inevitable) that someone will misuse the Ada exit statement. And it is likely that someone will correctly use the exit statment in exactly this fashion. Too bad you can't tell till runtime. ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 1990-02-21 22:49 ` Richard A Hammond 1990-02-21 23:14 ` John F Nixon @ 1990-02-22 5:39 ` Scott MacHaffie 1990-02-22 20:13 ` William Thomas Wolfe, 2847 ` (2 more replies) 1990-02-22 18:28 ` Mike Percy 1990-02-23 2:09 ` Douglas Miller 4 siblings, 3 replies; 60+ messages in thread From: Scott MacHaffie @ 1990-02-22 5:39 UTC (permalink / raw) In article <8103@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > the NEXT case. In other words, C requires the programmer to use a > dangerous construct on a routine basis. (the dangerous construct is the "break" statement) But if "break" were renamed "end case" then there wouldn't be any problem? > code associated with the else part. Thus, we have an inconsistency > in C's design: with one flow-of-control construct (the switch), it is > necessary to use a dangerous GOTO to achieve normal processing, whereas No, it is necessary to use a statement to indicate that the current case statement is finished...like an "end case" or the next "when => " in ADA. > with a similar flow-of-control construct (the if-else), the default is > reversed. Given such a language design, it should not surprise anyone > that programmers become confused, particularly when the constructs are > being used together. Some programmers become confused -- good programmers, and software engineers, don't. > specified situation has been executed. Ada also provides the exit > statement, a restricted GOTO which permits a loop to be exited early, > but this construct is not used (as is C's break) on a routine basis. In all the ADA I have seen, the preferred looping construct is a "loop" with exit statements sprinkled throughout it. On the other hand, C's "break" statement is only occasionally used to exit a loop prematurely. >> In my limited experience the cases where Ada is introduced into a >> programming environment also introduce lots of other good software >> engineering practices. For example, lots of people I know who >> program in C don't use LINT. I view it as a deficiency of management >> and not of the language that they don't use available tools. I don't use LINT. I use compilers that check certain things I want checked, like "no prototypes in scope". LINT does not catch the kinds of mistakes that I make. How many ADA programmers do you know of use LINT? > This is certainly true; Brooks and others have noted that the good > software engineering practices which are routinely introduced in > conjunction with the Ada language are responsible for more of the > resulting improvements than the fact that the Ada language was Well, these practices are certainly NOT being introduced in the universities (at least not here). > introduced. However, we cannot disregard that fact that Ada was > specifically designed to provide maximal support for the software > engineering process. C, on the other hand, was designed to provide No, ADA was designed to have everything. The fact that it (or some subset of it) can be used to do software engineering doesn't mean it was designed to do it. Software engineering can be done in any language, including C. > maximal support for the compilation process. Since compilers and > the CPU power required to operate them come far more cheaply than > programmers, and especially in view of the fact that better error > prevention is worth much more than faster compilation, it would seem > that the tradeoff made by Ada is certainly the one to be preferred. The "tradeoff made by ADA?" Do you mean poor code generation versus code that can be read by non-programmers? Or do you mean the language syntax that creates nightmares for maintenance? (Does Ada allow you to redefine the precedence of operators?) Or maybe you mean "language that the government will use" versus "language that non-government related software companies will use"? Scott MacHaffie ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-22 5:39 ` Scott MacHaffie @ 1990-02-22 20:13 ` William Thomas Wolfe, 2847 1990-02-23 17:32 ` Richard A Hammond 1990-02-22 20:48 ` Jeff Lawhorn 1990-02-23 2:00 ` Douglas Miller 2 siblings, 1 reply; 60+ messages in thread From: William Thomas Wolfe, 2847 @ 1990-02-22 20:13 UTC (permalink / raw) From machaffi@fred.cs.washington.edu (Scott MacHaffie): >> code associated with the else part. Thus, we have an inconsistency >> in C's design: with one flow-of-control construct (the switch), it is >> necessary to use a dangerous GOTO to achieve normal processing, whereas > > No, it is necessary to use a statement to indicate that the current case > statement is finished...like an "end case" or the next "when => " in ADA. Such a statement already exists: either the next "case Value:", or the } which ends the switch. Why is it necessary to use a "break"? >> with a similar flow-of-control construct (the if-else), the default is >> reversed. Given such a language design, it should not surprise anyone >> that programmers become confused, particularly when the constructs are >> being used together. > > Some programmers become confused -- good programmers, and software > engineers, don't. The problem cannot simply be defined out of existence by saying, in essence, that good programmers don't make mistakes. All human programmers make mistakes, and a well-designed language will help to minimize this particular tendency. In this case, C does not. >> This is certainly true; Brooks and others have noted that the good >> software engineering practices which are routinely introduced in >> conjunction with the Ada language are responsible for more of the >> resulting improvements than the fact that the Ada language was > > Well, these practices are certainly NOT being introduced in the > universities (at least not here). In that case, I strongly suggest that you immediately bring this fact to the attention of the software engineering faculty at washington.edu. At other universities (e.g., Clemson), Ada *is* introduced in conjunction with software engineering. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-22 20:13 ` William Thomas Wolfe, 2847 @ 1990-02-23 17:32 ` Richard A Hammond 1990-02-25 20:23 ` David Kassover 0 siblings, 1 reply; 60+ messages in thread From: Richard A Hammond @ 1990-02-23 17:32 UTC (permalink / raw) In article <8126@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: .... [ in discussion of the AT&T bug] > The problem cannot simply be defined out of existence by saying, > in essence, that good programmers don't make mistakes. All human > programmers make mistakes, and a well-designed language will help > to minimize this particular tendency. In this case, C does not. ^^^^^^^^ Uh Oh! I agree with Bill. The problem here is that the original request was for cases where a different language would have PREVENTED the error, that is, reduced the probability to 0.0 . Another example was a FORTRAN program fragment: DO 10 I = 1.100 which the compiler treated as: DO10I = 1.100 while the programmer wanted: DO 10 I = 1, 100 Using another language that was sensitive to spaces between characters would have PREVENTED the problem. Now the AT&T problem in C & Ada was: C Version Ada Version do { OUTER: loop ... ... switch ... case ... is { case ... : when ... => if ( ...) { if ... then ... ... break; exit; -- exits OUTER!! } end if; ... ... break; when ... => } /* end case */ end case; ... ... } while ( ...) ; exit OUTER when ... ; end loop OUTER; I agree with Bill that Ada would minimize the chance of getting an "exit" in there, since it doesn't need one at the end of each case. However, it wouldn't PREVENT it, since the Ada and C fragments are both not only legal, but sensible. So I claim that the AT&T problem does not fall in the same class as the FORTRAN do loop problem, switching to Ada would have made the mistake less likely but not removed the possibility of it entirely. Particularly if the programmer really had the misconception that exit/break left if statements. Rich Hammond ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-23 17:32 ` Richard A Hammond @ 1990-02-25 20:23 ` David Kassover 0 siblings, 0 replies; 60+ messages in thread From: David Kassover @ 1990-02-25 20:23 UTC (permalink / raw) In article <5498@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes: ... >I agree with Bill that Ada would minimize the chance of getting an "exit" >in there, since it doesn't need one at the end of each case. >However, it wouldn't PREVENT it, since the Ada and C fragments are both >not only legal, but sensible. Way back in the mists of time, before FORTRAN77 and Ratfor were inflicted on us, I was doing computer programming with a fortran preprocessor variously called FLEXTRAN, FLEX, FLECS, etc. One of the features of this preprocessor was that it provided 4 varieties of case statement, as well as an IF-THEN-ELSE construct. All four had optional catchall statements. We had the SELECT and the CONDITIONAL. SELECT was similar to Ada Case. One selected an expression, and specified cases for each. CONDITIONAL was more like an IF-THEN-ELSE, and was not strictly necessary. That is, one entered the conditional, and executed the code associated with the first of a list of conditions that was true. There were also the ENTER SELECT and the ENTER CONDITIONAL. Exactly like SELECT and CONDITIONAL, except that once a case was selected, control passed through to all subsequent cases, including a catchall if present. Similar to the C Switch. I have no idea why someone went to the trouble of providing more than a functionally complete set of control structures, but it was very handy, *IF* the programmer didn't choose the wrong one by mistake, or got confused as to which one he wanted. Oh, well, nothing has changed... By the way, if anyone could suggest a way to make a preprocessor whose output would be legal FORTRAN *and* a correct program, if the fortran language did not have an ASSIGNED GOTO construct, I would appreciate it. My mind doesn't work that way... ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-22 5:39 ` Scott MacHaffie 1990-02-22 20:13 ` William Thomas Wolfe, 2847 @ 1990-02-22 20:48 ` Jeff Lawhorn 1990-02-23 2:00 ` Douglas Miller 2 siblings, 0 replies; 60+ messages in thread From: Jeff Lawhorn @ 1990-02-22 20:48 UTC (permalink / raw) It seems to me that if the program in question had been thoroughly tested it would not matter if it had been written in C or Ada or Pascal or anything else. The bug would have been found, and AT&T's network would not have been knocked off the air. In **EVERY** language it is possible to write valid code that does not do what the programmer wants. This is why every possible code path should be tested before it is placed into a production system. Let's hope that AT&T didn't learn not to use C or Ada or whatever, but that they learned to test their software better before using it in a production system. -- Jeff Lawhorn lawhorn@opti.uucp opti!lawhorn@berick.uucp ucsd!sdsu!berick!opti!lawhorn ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-22 5:39 ` Scott MacHaffie 1990-02-22 20:13 ` William Thomas Wolfe, 2847 1990-02-22 20:48 ` Jeff Lawhorn @ 1990-02-23 2:00 ` Douglas Miller 1990-02-22 16:05 ` Dan L. Pierson 1990-02-23 17:45 ` Mike Harrison 2 siblings, 2 replies; 60+ messages in thread From: Douglas Miller @ 1990-02-23 2:00 UTC (permalink / raw) In article <10811@june.cs.washington.edu>, machaffi@fred.cs.washington.edu (Scott MacHaffie) writes: > In article <8103@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >> introduced. However, we cannot disregard that fact that Ada was >> specifically designed to provide maximal support for the software >> engineering process. C, on the other hand, was designed to provide > > No, ADA was designed to have everything. The fact that it (or some subset > of it) can be used to do software engineering doesn't mean it was designed > to do it. Valid but utterly vacuous point, as ADA *was* designed to provide maximal support for software engineering. I suppose its possible that another (hidden?) design goal was to "have everything". So what? > Software engineering can be done in any language, including C. Irrelevant --- the claim here is that ADA provides *maximal* *support* for the software engineering process. Like, if I said "Air travel is the fastest way to get to another city" and you said "You don't have to go by `plane. You could go by car, or even on foot", then I'd look at you with a slightly glazed expression, right? Sorry to labor this, but I've seen the above point made *too* many times. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-23 2:00 ` Douglas Miller @ 1990-02-22 16:05 ` Dan L. Pierson 1990-02-22 20:28 ` David Kassover 1990-02-24 19:52 ` Erland Sommarskog 1990-02-23 17:45 ` Mike Harrison 1 sibling, 2 replies; 60+ messages in thread From: Dan L. Pierson @ 1990-02-22 16:05 UTC (permalink / raw) In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes: Valid but utterly vacuous point, as ADA *was* designed to provide maximal support for software engineering. I suppose its possible that another (hidden?) design goal was to "have everything". So what? > Software engineering can be done in any language, including C. Irrelevant --- the claim here is that ADA provides *maximal* *support* for the software engineering process. Like, if I said "Air travel is the fastest way to get to another city" and you said "You don't have to go by `plane. You could go by car, or even on foot", then I'd look at you with a slightly glazed expression, right? Sorry to labor this, but I've seen the above point made *too* many times. This bit of ADA mythology (or dogma) has also been made too many times for me to remain silent. Yes, ADA did have a goal of maximal support for the software engineering process. However other goals (and the committee requirements and design process) largely subverted that goal by producing an excessively large, over-specified monster. You can certainly do software engineering in ADA, it is in most ways a better language for the purpose than C, but other languages such as Modula-3, Eiffel, and maybe Turing provide at least the software engineering benefits of ADA (though not all the "nifty" features*) in languages that are small enough to be useable, learnable, teachable, and efficiently implementable in less than a decade. I'm not interested in another C vs. ADA vs. my-favorite-language war, but I'm just plain tired of the line that ADA is equivalent to software engineering because the DOD and those who base their careers on it say so. *In fact, some of these "nifty" features present more opportunity for misuse, and thus software engineering drawbacks, than benefits. Operator overloading comes to mind... -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-22 16:05 ` Dan L. Pierson @ 1990-02-22 20:28 ` David Kassover 1990-02-24 19:52 ` Erland Sommarskog 1 sibling, 0 replies; 60+ messages in thread From: David Kassover @ 1990-02-22 20:28 UTC (permalink / raw) Wow, we are getting vicious, aren't we? In article <PIERSON.90Feb22110501@xenna.encore.com> pierson@encore.com (Dan L. Pierson) writes: >In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes: > Valid but utterly vacuous point, as ADA *was* designed to provide maximal > support for software engineering. I suppose its possible that another > (hidden?) design goal was to "have everything". So what? > > > Software engineering can be done in any language, including C. ... > >This bit of ADA mythology (or dogma) has also been made too many times >for me to remain silent. Yes, ADA did have a goal of maximal support >for the software engineering process. However other goals (and the ... >but I'm just plain tired of the line that ADA is equivalent to >software engineering because the DOD and those who base their careers >on it say so. >Internet: pierson@encore.com Ada vs C vs Pascal vs.... and mythology I think what I am going to write as follows are verifyable facts. I am not responsible for things not turning out as they were intended... Ada was designed by a committee (!!??? we can argue the merits of that elsewhere) which had certain aspects of the computer programming process that they wanted to address. Many of these aspects were based on real life experience (E.G. real-time programming, needing to acknowledge error conditions that make continuance undesirable) The committee succeeded in answering most of the desires, and where there was an irresolvable conflict, chose. Therefore, we have goto statements, no conditional compile, etc. Pascal was designed by an individual who had as his primary concern the production of a testbed from which to teach computer language design (or was it computer language compiler design. NOT THE SAME THING!) Furthermore, this individual was a proponent of a restrictive structured programming theory. Therefore, we have a rather incomplete language with some extremely annoying features. C, and Unix, were built, at least initially, by an individual who wanted to take a crack at building an operating system from scratch, on a more or less scrapped piece of hardware, while employed by an employer which was more or less liberal about such activities. Therefore we have a language, and OS, which is simple, and does some things very well indeed, but addresses other things not at all. Now, we're back to educated opinion. Ada, as implemented, did not achieve all it's goals. But I submit that it acheived many of them; that not all stated goals were even in the original mix; and that the set of goals was broader in scope than the goal sets of either C or Pascal. A long time ago, when I knew less than I do now, I said that Ada, as specified, was the embodiment of what a Pascal programmer thought a Cobol programmer ought to have at his disposal. I stand by that statement today. But still, for me, as a programmer working on a production job, Ada is the language of choice, all other things being equal (which they rarely are). For a personal programming job that is not likely to ever be touched by other than me, the language of choice is FORTRAN, simply because that is the first computer programming language I learned after BASIC (a very long time ago!), again all other things being equal. I would like to see this newsgroup return to discussions of Ada and implementations of Ada. Or maybe we could create a sub-newsgroup like comp.lang.flame?? 8-) Dave ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-22 16:05 ` Dan L. Pierson 1990-02-22 20:28 ` David Kassover @ 1990-02-24 19:52 ` Erland Sommarskog 1 sibling, 0 replies; 60+ messages in thread From: Erland Sommarskog @ 1990-02-24 19:52 UTC (permalink / raw) Dan L. Pierson (pierson@encore.com) writes: >*In fact, some of these "nifty" features present more opportunity for >misuse, and thus software engineering drawbacks, than benefits. >Operator overloading comes to mind... Of course you could do really ugly things with operator overloading, particulary in combination with RENAME. But in a good software engineering environment with code reviews you would never be allowed to do them. Operator overloading is an important feature. No wonder that both C++ and Eiffel has incorporated varities thereof. (Eiffel doesn't really have overloading, but well infix routines.) Why? Well, in my daily work, which is in Pascal, I have to struggle with quadword integers. An expression like a := a + (b*c) DIV d + e becomes when a, b and e are quads: a := Add_quads(a, Add_quads( Div_quads(Mult_quads(b, Conv_lw_to_qw(c)), Conv_lw_to_qw(d)), e)) which is not very readable. Even more important is that if have written the standard integer version above and later discover that I have to change to quads, I don't have to change any existing code. (Of course the example above can be alleviated in various ways. The routines used are the standard routines at the site I am on.) -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-23 2:00 ` Douglas Miller 1990-02-22 16:05 ` Dan L. Pierson @ 1990-02-23 17:45 ` Mike Harrison 1990-02-27 2:02 ` Douglas Miller 1 sibling, 1 reply; 60+ messages in thread From: Mike Harrison @ 1990-02-23 17:45 UTC (permalink / raw) In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes: >Valid but utterly vacuous point, as ADA *was* designed to provide maximal >support for software engineering. I suppose its possible that another >(hidden?) design goal was to "have everything". So what? > Wrong ! - Ada was designed primarily to save DoD money, secondarily to support very long in-service life software (by simplifying the maintenance process), with all kinds of other goodies as a tertiary aim. Way back in (about) 1975 HOLWG showed that DoD was spending huge sums on s/w in embedded systems, which were programmed in >300 languages (including ~ 70 different, often incomptible versions of JOVIAL). The idea of Ada (was Ironman etc.) was to provide a *single* language in which almost all embedded operational military s/w would be written, then it would only be necessary to keep one kind of programmer - an Ada programmer. Those of us working on Ada and its environments (things which led to Stoneman) in those days were serious about this people portablity (which was the prime motivation for the NO SUBSETS, NO SUPERSETS policy). Whether Ada, its implementers, DoD or anyone else succeded in these aims is a matter of personal taste, but I believe that the aims were good and the spirit which motivated most of the early workers was laudable. [Whatever became of paths and boxes?] Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS; ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-23 17:45 ` Mike Harrison @ 1990-02-27 2:02 ` Douglas Miller 0 siblings, 0 replies; 60+ messages in thread From: Douglas Miller @ 1990-02-27 2:02 UTC (permalink / raw) In article <4174@ganymede.inmos.co.uk>, mph@lion.inmos.co.uk (Mike Harrison) writes: > In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes: >>Valid but utterly vacuous point, as ADA *was* designed to provide maximal >>support for software engineering. I suppose its possible that another >>(hidden?) design goal was to "have everything". So what? >> > Wrong ! - Ada was designed primarily to save DoD money, secondarily to support > very long in-service life software (by simplifying the maintenance process), > with all kinds of other goodies as a tertiary aim. I know, these were the *requirements*. ADA was *designed* to meet these requirements by providing maximal support for software engineering. Alternatively I could argue that the requirements you mention basically define what software engineering is, and you are just nitpicking. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 ` (2 preceding siblings ...) 1990-02-22 5:39 ` Scott MacHaffie @ 1990-02-22 18:28 ` Mike Percy 1990-02-23 2:09 ` Douglas Miller 4 siblings, 0 replies; 60+ messages in thread From: Mike Percy @ 1990-02-22 18:28 UTC (permalink / raw) From article <8103@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): [Ada is great, Ada is wonderful, nothing can beat Ada, if you don't program in Ada you are stupider than worm-slime, blah blah blah] I've used Ada Bill, I even liked it. But, I am really getting tired of reading your diatribes against every other programming language, of reading your praises of Ada to the exclusion of all others. I use the language I feel is best for the particular problem at hand. I drop into assembly to optimize a speed-critical section of code. I use C for portability (right, I know, there are n fully verified Ada compilers running of x different machines, so how can Ada not be portable?) and speed of coding (my speed is higher in C than in Ada or any other language, this is subject to change of course), I use COBOL at work because that is the language the systems I maintain, I use a quasi-4GL when I can to spit out 3GL code. SOmetimes I use SNOBOL, Lisp, or Prolog, or Pascal. I've seen some Ada code that must have been written by brain-damaged idiots. And I've seen some beautifully written assembly. The point is, that the programming practices are what makes the difference. It is entirely reasonable to engineer software in C or Prolog or... Just as it is reasonably easy to mangle Ada. Granted, Ada lends itself to good software engineering practices, probably you could even say that it encourages it. However, it does not guarantee it, nor does the failure to use Ada preclude good software engineering practices. My guess is that Ada will gain a load of users and their respect when there is a Microsoft Ada or better yet (or worse yet) a Turbo Ada. Anyway please try to keep your pro-Ada, anti-everything-else stuff in check. -- 'I just couldn't convince the voters that Dukakis was Greek for "Bubba".' -- Lloyd Benson explaining why the Democrats didn't carry Texas ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 ` (3 preceding siblings ...) 1990-02-22 18:28 ` Mike Percy @ 1990-02-23 2:09 ` Douglas Miller 4 siblings, 0 replies; 60+ messages in thread From: Douglas Miller @ 1990-02-23 2:09 UTC (permalink / raw) In article <8103@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > Ada, on the other hand, is consistent: in both the if and case statements, > the default is to exit the construct once the code associated with the > specified situation has been executed. Ada also provides the exit > statement, a restricted GOTO which permits a loop to be exited early, > but this construct is not used (as is C's break) on a routine basis. Huh? Surely EXIT is the only and sensible way to exit a simple loop? Why do you call EXIT a `restricted GOTO'? This makes as much sense to me as describing a statement as a performing a `restricted GOTO' from the previous statement. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-21 16:49 ` Richard A Hammond 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 @ 1990-02-22 0:25 ` David Kassover 1990-02-22 3:42 ` Richard A Hammond 1 sibling, 1 reply; 60+ messages in thread From: David Kassover @ 1990-02-22 0:25 UTC (permalink / raw) In article <5432@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes: >In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: > >>For a research project I am collecting information about the risk of >>choosing the wrong programming language. In particular I am looking >>for problems that could have been avoided if another (a better) >>programming language would have been used. > >>I know of these three such stories: > ... >> 3. The AT&T breakdown a month ago was caused by a break statement >> in C. See the following mail (multiple forwarding headers deleted): > >What other programming language? Only one without any GOTO or restricted >GOTO (e.g. exit, break, ...). This leaves out Ada!!!!!! > >Similar bug in Ada: (Cut down for posting, but gives the flavor) > >In my limited experience the cases where Ada is introduced into a >programming environment also introduce lots of other good software >engineering practices. For example, lots of people I know who >program in C don't use LINT. I view it as a deficiency of management >and not of the language that they don't use available tools. OK. First, I apologise for mis-representing the "classic" FORTRAN goof (There's one that's actually ambiguous to the compiler, involving FORMAT statements and Hollerith constants, but I can never remember it) Now, AT&T breakdown: You show how this could happen in Ada. Ok, it could. But ada allows one to "name" loops, and use those names in exit statements, especially useful when you want to break out of an inner and an outer loop. In your example, you didn't do so, since the C code could not. But you could have. Looking back at the last 20Klines of Ada I've written recently, I've used named loops roughly twice. Specifically to avoid ambiguity to me when I look at the code, but it helps make sure I did it right, too. You go on to bemoan the lack of use of LINT. I submit that, since we're not dependent on underpowered pdp9's or 11's anymore, then LINT should be built into the compiler, or there as the default option (to be turned off at the user's risk) And onward, to problems that are exacerbated by the language. Time and again, my C development people spend oodles of effort tracking down something that ends up being resolved by discovering a header file that was changed, but not *all* of the dependent code was recompilied. Use make, you say? Sure, but someone's got to write the make script, whose language is no gem, either. Ada's insistence on specification recompile (and lack of a include processor) cause the dependency tree to be built and modified automatically. (in Vax ada, you can enter "foreign language" object modules into the library, so they, too, can participate in obsolescence analysis. I don't know if anyone else provides this, or how well it works) On a par in terms of frequency with the above is the case of the non-catchalled case statement. In ada, if you have a case statement of an enumerated type, and you do not provide a case for every member of the type or a when others => clause, the compiler signals an error. No, this doesn't stop someone putting a when others => null; in, but most of us either use the compiler to remind us to put in an appropriate case or cause a fatal error to occur in the catchall, the theory being that it will blow up in testing, and the appropriate case added. Finding this thing in C is a bear, especially when, if your code is like mine, three quarters of it is conditional compile based on flags set in a header file somewhere. And just as a final note: I have demonstrated many times that it is possible to write FORTRAN in Ada. About the only places I haven't been able to do so, if I really wanted to, have been APL and assembler. That doesn't mean that either Ada or FORTRAN are valueless. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-22 0:25 ` problems/risks due to programming language, stories requested David Kassover @ 1990-02-22 3:42 ` Richard A Hammond 1990-02-22 16:08 ` David Kassover 1990-02-22 16:21 ` David Kassover 0 siblings, 2 replies; 60+ messages in thread From: Richard A Hammond @ 1990-02-22 3:42 UTC (permalink / raw) In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: >For a research project I am collecting information about the risk of >choosing the wrong programming language. In particular I am looking >for problems that could have been avoided if another (a better) >programming language would have been used. RE: AT&T example OK folks, I was not trying to say that C was as good as Ada, I merely pointed out that in both C and Ada one could have a legal program that had a restricted goto (C "break", Ada "exit") inside an if, and that neither language's compilers could detect whether the programmer really wanted that or not. This, to my mind, makes the example not fit the class that was requested, of cases where a different language would have prevented the problem. In article <5458@crdgw1.crd.ge.com> kassover@jupiter.crd.ge.com (David Kassover) writes: ... >Time and again, my C development people spend oodles of effort >tracking down something that ends up being resolved by >discovering a header file that was changed, but not *all* of the >dependent code was recompilied. Use make, you say? Sure, but >someone's got to write the make script, whose language is no gem, >either. The oodles of time is an exageration, since, painful though it might be, writing the make script would solve the problem once and for all. This suggests that the cost to find the numerous problems is less than to write a make script. By the way, there are tools available to automatically generate most of the makefile. Besides, if you have a make script you can cause lint to run automatically, which is a nice side benefit. >Ada's insistence on specification recompile (and lack of a >include processor) cause the dependency tree to be built and >modified automatically. (in Vax ada, you can enter "foreign >language" object modules into the library, so they, too, can >participate in obsolescence analysis. I don't know if anyone >else provides this, or how well it works) And it is a real pain when the compiler has a bug in the implementation, as does the Ada compiler we're using. If you change a generic body it messes up its internal information and you end up recompiling everything, so we end up avoiding the built-in "make" of Ada and writing make scripts to get the proper recompilations done. Maintaining the make scripts costs less time than recompiling everything every time you change a generic body. Building everything into the compiler does have disadvantages. >On a par in terms of frequency with the above is the case of the >non-catchalled case statement. ... >Finding this thing in C is a bear, especially when, if your code >is like mine, three quarters of it is conditional compile based >on flags set in a header file somewhere. So, in Ada you either write incomplete code (because the compiler will catch it) or you raise an exception(I imagine) in the "others" case. I don't see why you can't adopt the second solution in C. If it happens often, adopt a coding style to minimize it, always put "default: abort();" in your switch statements. Your complaints remind me of the old chinese saying (Rich's paraphrase) Fooled once, shame on the language which fooled you. Fooled twice, shame on you. Rich Hammond ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-22 3:42 ` Richard A Hammond @ 1990-02-22 16:08 ` David Kassover 1990-02-22 16:21 ` David Kassover 1 sibling, 0 replies; 60+ messages in thread From: David Kassover @ 1990-02-22 16:08 UTC (permalink / raw) In article <5464@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes: >In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: > >>For a research project I am collecting information about the risk of >>choosing the wrong programming language. >In article <5458@crdgw1.crd.ge.com> kassover@jupiter.crd.ge.com (David Kassover) writes: >... >>Time and again, my C development people spend oodles of effort >>tracking down something that ends up being resolved by >>discovering a header file that was changed, but not *all* of the >>dependent code was recompilied. Use make, you say? Sure, but >>someone's got to write the make script, whose language is no gem, >>either. > >The oodles of time is an exageration, since, painful though it >might be, writing the make script would solve the problem once >and for all. > "Oodles" is a rather imprecise term. I apologize. But you aren't here. Almost time I visit my development people, they are chasing some sort of bug that was traced to this case, or a missing catchall. I may have sampling error problems, I admit it. >>Ada's insistence on specification recompile (and lack of a >>include processor) cause the dependency tree to be built and >>modified automatically. (in Vax ada, you can enter "foreign >>language" object modules into the library, so they, too, can >>participate in obsolescence analysis. I don't know if anyone >>else provides this, or how well it works) > >And it is a real pain when the compiler has a bug in the implementation, >as does the Ada compiler we're using. >... If your compiler has a bug (Since Ada is thoroughly standardized, one standard, no extensions, no subsets) then you should get it fixed or get a different compiler. >Maintaining the make scripts costs less time than recompiling >everything every time you change a generic body. >Building everything into the compiler does have disadvantages. >... Well, you're there, and I'm not. But attempting to do a professional job with amateur's tools, or amateur quality tools, is likely to be frustrating, among other things. This is not a problem with the language, it's a problem with the implementation your stuck with. By the way, the product line I am dealing with is supported on more than 20 different operating systems, only some of which are Unix, or Unix-like, some of which do not offer a make-analog, and even of the ones which do, the make scripts have to be (only sometimes subtly) different. I simply do not have time, nor the charter, to implement make for everybody > >>On a par in terms of frequency with the above is the case of the >>non-catchalled case statement. ... > >>Finding this thing in C is a bear, especially when, if your code >>is like mine, three quarters of it is conditional compile based >>on flags set in a header file somewhere. > >So, in Ada you either write incomplete code (because the compiler >will catch it) or you raise an exception(I imagine) in the "others" >case. >... No, I didn't write incomplete code and wait for the compiler to catch it. (I've used this technique elsewhere, though). It is common, in the ada I have seen, to define in a package specification an enumerated type. Later on, someone adds an element to the type. (e.g. support for a different type of data structure, or even, as is the case, add a new package to the system. (this system keeps track of the names of it's packages, in order to generate traceback information during runtime user errors)) The code in the package body contains a case statement on the enumerated type. It was not created incomplete, but it was RENDERED incomplete by the insertion of a new element. Since recompilation is of this body is forced, without having to remember to modify the make script (we've already forgotten to modify the package body, remember), this error is fixed before the module gets out of unit test. this is not to say that the compilable code in the case statement is not erroneous, but falling off the end of the case statement is probably at least as bad. That is, some human has to exert effort to allow the case statement to be fallen through, rather than it being allowed to happen. > >If it happens often, adopt a coding style to minimize it, always >put "default: abort();" in your switch statements. > >... This is the real world. I have little time to fight with my people over personal style, and I don't want to be viewed as a tin pot tyrant over stylistic issues. My concerns are getting the product out there, with as few errors as possible. Ada appears to help in this regard more than C does. I'm sure you and your employers have a somewhat different agenda. Dave Kassover ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-22 3:42 ` Richard A Hammond 1990-02-22 16:08 ` David Kassover @ 1990-02-22 16:21 ` David Kassover 1 sibling, 0 replies; 60+ messages in thread From: David Kassover @ 1990-02-22 16:21 UTC (permalink / raw) by the way, are we discussing Ada here, or structured programming? I've already made up my mind (LONG AGO) about one of them... :-) Dave ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-20 22:28 problems/risks due to programming language, stories requested Gerald Baumgartner 1990-02-21 16:49 ` Richard A Hammond @ 1990-02-23 18:11 ` Thomas Vachuska 1990-02-24 0:13 ` Mark Brader 1990-02-27 19:30 ` Bill Leonard 3 siblings, 0 replies; 60+ messages in thread From: Thomas Vachuska @ 1990-02-23 18:11 UTC (permalink / raw) Maybe I am missing the point here, but to the best of my knowledge Ada "exit" statement is allowed only within a "named loop|loop" statement (unless it appears in a "subprogram|package|generic|task|accept body" which is enclosed within that "loop" statement, to be precise). And as far as I know similar restrictions apply for the use of the C "break" statement which terminates the execution of either the "while|do|for" or "switch" statement. Neither of these are to abandon execution of an "if" statement block. I would agree that it is easier to get in trouble in the following situation in C which does not have a counterpart in Ada since Ada's "exit" exits ONLY the "loop" statement. switch (trouble) { case PROGRAMMER_SCREW_UP: for (;;) { break; /* intended for exiting the "switch", BUT... */ } case ... . . } Thomas Vachuska (-- Ada Addict) ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-20 22:28 problems/risks due to programming language, stories requested Gerald Baumgartner 1990-02-21 16:49 ` Richard A Hammond 1990-02-23 18:11 ` Thomas Vachuska @ 1990-02-24 0:13 ` Mark Brader 1990-02-27 19:30 ` Bill Leonard 3 siblings, 0 replies; 60+ messages in thread From: Mark Brader @ 1990-02-24 0:13 UTC (permalink / raw) Gerald Baumgartner (gb@cs.purdue.EDU) writes in many groups: > There is the famous story that a Mariner probe got lost > because of the Fortran statement `DO 3 I = 1.3' (1.3 instead > of 1,3) ... It is a nice story but, as far as I know, NASA used > Jovial at that time and not Fortran. Just for the record, the above was definitively shown to be fictional according to authoritative references given in comp.risks (= Risks Digest), issue 9.75 (I hear), not too many months ago. There is at least one textbook that states it as truth; this is wrong. The actual reason for the loss of Mariner I was an error in code used in recovering from a hardware failure; the code had been based on handwritten equations, and in transcribing one of these, an overbar was deleted from one letter. A story which may have been the true origin of the "DO statement myth" was posted fairly recently in alt.folklore.computers; the article cited a program at NASA that did enter production use with a dot-for-comma bug in a DO statement, but it wasn't a spacecraft flight control program. (I didn't save the details and would be happy to see them again.) Followups directed to alt.folklore.computers. -- Mark Brader "I'm not going to post a revision: even USENET utzoo!sq!msb, msb@sq.com readers can divide by 100." -- Brian Reid This article is in the public domain. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-20 22:28 problems/risks due to programming language, stories requested Gerald Baumgartner ` (2 preceding siblings ...) 1990-02-24 0:13 ` Mark Brader @ 1990-02-27 19:30 ` Bill Leonard 1990-02-28 18:57 ` Paul Snively 3 siblings, 1 reply; 60+ messages in thread From: Bill Leonard @ 1990-02-27 19:30 UTC (permalink / raw) In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: I received the following on AT&T's famous bug (and have deleted multiple forwarding headers): | | Subject: AT&T Bug | | Date: Fri Jan 19 12:18:33 1990 | | | | This is the bug that cause the AT&T breakdown | | the other day (no, it wasn't an MCI virus): | | | | In the switching software (written in C), there was a long | | "do . . . while" construct, which contained | | a "switch" statement, which contained | | an "if" clause, which contained a | | "break," which was intended for | | the "if" clause, but instead broke from | | the "switch" statement. | | Again it looks like this bug wouldn't have occurred in another programming language. I can't resist saying that this last statement seems to me to be utter nonsense. What programming language (read, compiler) can read the programmer's mind and tell what he meant? The use of the "break" statement was a logic error (actually, it sounds like it was a lack of knowledge of the language, since "break" does not apply to "if"). I can't imagine a programming language that could discern this type of error. [If I use WHILE instead of IF, for instance, I can expect some things to work and some not. Yet I seriously doubt any compiler could possibly detect this error.] I certainly think programmers often choose an inappropriate language, but I shy away from anecdotal stories like these because they seem (to me) to spread a lot of misinformation. Unless you implement a project in multiple languages, it is nothing more than a guess to say what would have happened if the project had been implemented in some other language. Perhaps you would have discovered an even more serious flaw in that language, or you might simply find it was no better or worse than the one you chose, just different. Most of the stories I have heard along these lines all struck me as missing the point: how well was the program tested? Were there code reviews? Design reviews? All of these techniques are proven to reduce errors. Most of the errors in these stories (e.g., the infamous dot-versus-comma one) should have been found with even rudimentary testing. Use of an inappropriate language is no excuse for abandoning other techniques of good software engineering. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com or hcx1!bill@uunet.uu.net ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-27 19:30 ` Bill Leonard @ 1990-02-28 18:57 ` Paul Snively 1990-02-28 21:35 ` Jason Coughlin ` (4 more replies) 0 siblings, 5 replies; 60+ messages in thread From: Paul Snively @ 1990-02-28 18:57 UTC (permalink / raw) In article <BILL.90Feb27143004@hcx2.ssd.harris.com> bill@ssd.harris.com (Bill Leonard) writes: > In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: > Again it looks like this bug wouldn't have occurred in another > programming language. > > I can't resist saying that this last statement seems to me to be utter > nonsense. What programming language (read, compiler) can read the > programmer's mind and tell what he meant? The use of the "break" statement > was a logic error (actually, it sounds like it was a lack of knowledge of > the language, since "break" does not apply to "if"). I can't imagine a > programming language that could discern this type of error. [If I use > WHILE instead of IF, for instance, I can expect some things to work and > some not. Yet I seriously doubt any compiler could possibly detect this > error.] > > I certainly think programmers often choose an inappropriate language, but I > shy away from anecdotal stories like these because they seem (to me) to > spread a lot of misinformation. Unless you implement a project in multiple > languages, it is nothing more than a guess to say what would have happened > if the project had been implemented in some other language. Perhaps you > would have discovered an even more serious flaw in that language, or you > might simply find it was no better or worse than the one you chose, just > different. > > Most of the stories I have heard along these lines all struck me as missing > the point: how well was the program tested? Were there code reviews? > Design reviews? All of these techniques are proven to reduce errors. Most > of the errors in these stories (e.g., the infamous dot-versus-comma one) > should have been found with even rudimentary testing. > > Use of an inappropriate language is no excuse for abandoning other techniques > of good software engineering. I don't think that anyone's claiming that it is an excuse; I believe the point was that some languages applied to some tasks lend themselves to error more than another language applied to the same task. If you wish to interpret the above story as a rather pointed jab at the C programming language, and object to C being treated that way, that's fine, but please just say so. For what it's worth, my personal opinion is that C lends itself to precisely the kinds of errors noted above--when does break work and when doesn't it, and why in God's name do you need it in switch statements in the first place, etc. I believe that it's C's historical looseness that is simultaneously its greatest weakness, when it leads to errors like this, and its greatest strength--C doesn't restrict you; C is mean and lean; C is close to the hardware; real programmers use C; even, God help us, C is the only language you need! We all know C programmers whose machismo is thus huffed and puffed up (another of my personal opinions is that the per capita arrogance of C programmers far outweighs the per capita arrogance of any other language-aficionado group). Now to get back to the important point: what language would have been better for the task in question? Well, I hate to say it, but it's extremely unlikely that such an error would have been made in Pascal, since Pascal doesn't require you to explicitly break from case...of constructs. Before the flames start, let me just add: no, I don't necessarily prefer Pascal over C for all tasks. I generally attempt to choose the right tool for the job, rather than falling into the "when all you have is a hammer, everything looks like a nail" trap. Standard Disclaimer. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-28 18:57 ` Paul Snively @ 1990-02-28 21:35 ` Jason Coughlin 1990-03-01 19:00 ` Barry Margolin 1990-03-01 15:33 ` problems/risks due to programming language, stories requested Jeff Dalton ` (3 subsequent siblings) 4 siblings, 1 reply; 60+ messages in thread From: Jason Coughlin @ 1990-02-28 21:35 UTC (permalink / raw) From article <6960@internal.Apple.COM>, by chewy@apple.com (Paul Snively): > For what it's worth, my personal opinion is that C lends itself to > precisely the kinds of errors noted above--when does break work and when > doesn't it, and why in God's name do you need it in switch statements in > the first place, etc. Gee, if you read the language defn you'd know exactly when break applies and when break doesn't. It seems to me that it is the programmer's responsibility to know the language in which he is going to implement said project -- it's not necessarily the language's responsibility to know the programmer didn't read the defn. > Well, I hate to say it, but it's extremely unlikely that such an error > would have been made in Pascal, since Pascal doesn't require you to > explicitly break from case...of constructs. And without knowing the project, you have no business making the assertion that Pascal was better than C [especially on a Unix box] or that C was better than Pascal [especially on a VMS box]. -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx ) "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of." - They Might Be Giants ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-28 21:35 ` Jason Coughlin @ 1990-03-01 19:00 ` Barry Margolin 1990-03-02 13:31 ` Richard A Hammond 0 siblings, 1 reply; 60+ messages in thread From: Barry Margolin @ 1990-03-01 19:00 UTC (permalink / raw) In article <1990Feb28.213543.21748@sun.soe.clarkson.edu> jk0@image.soe.clarkson.edu (Jason Coughlin) writes: > Gee, if you read the language defn you'd know exactly when break >applies and when break doesn't. It seems to me that it is the >programmer's responsibility to know the language in which he is going to >implement said project -- it's not necessarily the language's responsibility >to know the programmer didn't read the defn. What would you say if a car designer used a similar excuse: Gee, if you'd read the owner's manual for the 6000SUX you'd know that you have to turn the radio off before stepping on the brake pedal. It seems to me that it is the driver's responsibility to know the car he's driving -- it's not necessarily the manufacturer's responsibility to know that the driver didn't read the manual. Yes, it's the resposibility of the programmer to know the language. But it's the responsibility of language designers to design languages reasonably. If programmer-friendliness weren't an issue we'd still be programming in machine language. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-01 19:00 ` Barry Margolin @ 1990-03-02 13:31 ` Richard A Hammond 1990-03-02 19:26 ` William Thomas Wolfe, 2847 0 siblings, 1 reply; 60+ messages in thread From: Richard A Hammond @ 1990-03-02 13:31 UTC (permalink / raw) Slowly, and carefully, for Bill Wolfe's understanding, let's go through this once more. The original article asked for examples of cases where using a different language would have prevented the error. He gave 3 examples, one of which was: | | Subject: AT&T Bug | | Date: Fri Jan 19 12:18:33 1990 | | | | This is the bug that cause the AT&T breakdown | | the other day (no, it wasn't an MCI virus): | | | | In the switching software (written in C), there was a long | | "do . . . while" construct, which contained | | a "switch" statement, which contained | | an "if" clause, which contained a | | "break," which was intended for | | the "if" clause, but instead broke from | | the "switch" statement. I claim that this information is insufficient to find C guilty in this case. This is not to say that you can't find examples in C of such problems. To name a few: 1) Comments with Begin/End delimiters can easily hide code if one leaves out the end comment delimiter. Particularly bad if the compiler doesn't warn about nested comments. This also applies to Pascal, CMS-2, JOVIAL, ... 2) Writing : if ( a = b ) rather than: if ( a == b ) 3) Leaving out the "break" at the end of a case. All these are directly caused by C's language design and another language would avoid one or more of them (Ada avoids them all). If the explanation for the AT&T bug was: we originally had: we changed it to: case ...: case ...: if (...) { stmts_a stmts_a; break; break; -- should have removed } stmts_b; Then I would agree that it is possible to follow Bill's argument and assign the bug to the language, although even there it is a bit of a stretch. But, the explanation is "... a "break," which was intended for the "if" clause." Which doesn't support any conclusion other than the programmer didn't know the language. Why re-hash this? Well, I'm tired of Bill Wolfe's arguments which run: We know that Communism is evil. We know that they had a bad reactor accident. Therefore, changing to capitalism would have prevented the reactor accident! I suggest that Bill needs some more elementary logic courses if he really thinks that the statement of the AT&T bug supports his conclusion. It would be very helpful if the original poster (from Purdue) explained why he thought that the bug statement supported assigning it to the class of bugs prevented by using a different language. I agree with Bill that C does not provide very good support for the software engineering process. I think the examples I gave above are clear examples, the AT&T bug statement is not. Rich Hammond ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 13:31 ` Richard A Hammond @ 1990-03-02 19:26 ` William Thomas Wolfe, 2847 1990-03-02 22:19 ` Richard A Hammond 1990-03-03 20:18 ` Charles E Eaker 0 siblings, 2 replies; 60+ messages in thread From: William Thomas Wolfe, 2847 @ 1990-03-02 19:26 UTC (permalink / raw) From hammondr@sunroof.crd.ge.com (Richard A Hammond): % | | In the switching software (written in C), there was a long % | | "do . . . while" construct, which contained % | | a "switch" statement, which contained % | | an "if" clause, which contained a % | | "break," which was intended for % | | the "if" clause, but instead broke from % | | the "switch" statement. > > Which doesn't support any conclusion other than the programmer didn't know > the language. Not exactly. There is a lack of orthogonality in that similar flow-of-control constructs do not terminate in similar ways. If one is using the if statement, termination is automatic. If one is using the switch statement, a break is required. It is this lack of orthogonality which leads to potential problems. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 19:26 ` William Thomas Wolfe, 2847 @ 1990-03-02 22:19 ` Richard A Hammond 1990-03-06 21:54 ` John Boone 1990-03-03 20:18 ` Charles E Eaker 1 sibling, 1 reply; 60+ messages in thread From: Richard A Hammond @ 1990-03-02 22:19 UTC (permalink / raw) In article <8211@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From hammondr@sunroof.crd.ge.com (Richard A Hammond): >% | | In the switching software (written in C), there was a long >% | | "do . . . while" construct, which contained >% | | a "switch" statement, which contained >% | | an "if" clause, which contained a >% | | "break," which was intended for >% | | the "if" clause, but instead broke from >% | | the "switch" statement. >> Which doesn't support any conclusion other than the programmer didn't know >> the language. > Not exactly. There is a lack of orthogonality in that similar > flow-of-control constructs do not terminate in similar ways. If > one is using the if statement, termination is automatic. If one > is using the switch statement, a break is required. It is this > lack of orthogonality which leads to potential problems. ^^^^^^^^^ weasel words!! Potential cause /= actual cause. Reduced probability /= 0.0 probability Daggone it Bill, why don't you try to understand? You're quoting this out of context, the whole point of my posting was that the statement of the bug does not provide sufficient information to say that changing the language would have PREVENTED the problem. I gave 3 other examples (of C code problems) where the bug was one that would have been PREVENTED by use of Ada. Rich Hammond ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 22:19 ` Richard A Hammond @ 1990-03-06 21:54 ` John Boone 0 siblings, 0 replies; 60+ messages in thread From: John Boone @ 1990-03-06 21:54 UTC (permalink / raw) In article <8211@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Not exactly. There is a lack of orthogonality in that similar > flow-of-control constructs do not terminate in similar ways. If > one is using the if statement, termination is automatic. If one > is using the switch statement, a break is required. It is this > lack of orthogonality which leads to potential problems. This is a minor flame, but I feel it's necessary since literally millions :-) of CS students worldwide read these news groups and learn from them. So I think you should be more careful using four-syllable words :-) Orthogonal means, roughly, "at right angles to" - so I think your point is really BECAUSE of orthogonality in the flow-of-control constucts [ for C ] which leads to potential problems ... etc. -- ........................................................................... : J. M. Boone : : : : Tenacity of purpose for a rightful cause : ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 19:26 ` William Thomas Wolfe, 2847 1990-03-02 22:19 ` Richard A Hammond @ 1990-03-03 20:18 ` Charles E Eaker 1990-03-03 21:11 ` Invalid analogy William Thomas Wolfe, 2847 1 sibling, 1 reply; 60+ messages in thread From: Charles E Eaker @ 1990-03-03 20:18 UTC (permalink / raw) In article <8211@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From hammondr@sunroof.crd.ge.com (Richard A Hammond): >% | | In the switching software (written in C), there was a long >% | | "do . . . while" construct, which contained >% | | a "switch" statement, which contained >% | | an "if" clause, which contained a >% | | "break," which was intended for >% | | the "if" clause, but instead broke from >% | | the "switch" statement. >> >> Which doesn't support any conclusion other than the programmer didn't know >> the language. > > Not exactly. There is a lack of orthogonality in that similar > flow-of-control constructs do not terminate in similar ways. If > one is using the if statement, termination is automatic. If one > is using the switch statement, a break is required. It is this > lack of orthogonality which leads to potential problems. Ok, so the implied orthogonality of Ada means that, without putting a whole lot of thought into it, I can map the above C outline to Ada as follows: In the switching software (TRANSLATED to Ada), there was a long "LOOP" construct, which contained a "CASE" statement, which contained an "IF" clause, which contained an "EXIT," which was intended for the "IF" clause, but instead broke from the "LOOP" statement. and if there's a mistake here, it's because of the lack of orthogonality of Ada (which we all know is laughable) rather than any misunderstanding of the language on my part. Right? Hmm, maybe I'll stop working in Ada and go back to C. I like the idea of the language taking the wrap for what some misguided souls have viewed as my mistakes. But wait! Maybe I can stick with Ada. All I have to do is show, somehow, that Ada is not all that orthogonal ... hmm ... -- Chuck Eaker | eaker@sunbelt.crd.ge.com Software Engineering Program | eaker@crdgw1.UUCP GE Corporate Research & Development Center | (518) 387-5964 P.O. Box 8, K-1 3C12 Schenectady, NY 12301 | 8*833-5964 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Invalid analogy 1990-03-03 20:18 ` Charles E Eaker @ 1990-03-03 21:11 ` William Thomas Wolfe, 2847 1990-03-03 23:26 ` I Wish ` (2 more replies) 0 siblings, 3 replies; 60+ messages in thread From: William Thomas Wolfe, 2847 @ 1990-03-03 21:11 UTC (permalink / raw) From eaker@sunbelt.crd.ge.com (Charles E Eaker): >> [In C] similar flow-of-control constructs do not terminate in >> similar ways. If one is using the if statement, termination is >> automatic. If one is using the switch statement, a break is required. > % [An invalid analogy is attempted:] % "LOOP" construct, which contained % a "CASE" statement, which contained % an "IF" clause, which contained an % "EXIT," which was intended for % the "IF" clause, but instead broke from % the "LOOP" statement. Notice: "similar flow-of-control constructs". Both the case and the if statements execute different sections of code depending on the value of a controlling expression. A loop is a flow-of-control construct, but not one which is similar to the if or case constructs, which are so closely related that one is a special case of the other. This extreme similarity, unfortunately, does not extend to C's concept of how the two should be supported within the programming language. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Invalid analogy 1990-03-03 21:11 ` Invalid analogy William Thomas Wolfe, 2847 @ 1990-03-03 23:26 ` I Wish 1990-03-05 19:51 ` John F Nixon 1990-03-09 17:20 ` Tony Sanders 2 siblings, 0 replies; 60+ messages in thread From: I Wish @ 1990-03-03 23:26 UTC (permalink / raw) In article <8222@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > From eaker@sunbelt.crd.ge.com (Charles E Eaker): >> [In C] similar flow-of-control constructs do not terminate in >> similar ways. If one is using the if statement, termination is >> automatic. If one is using the switch statement, a break is required. [his example, a nested loop/if/switch/etc.] > Notice: "similar flow-of-control constructs". Both the case and > the if statements execute different sections of code depending on > the value of a controlling expression. [...] > This extreme similarity, unfortunately, does not extend to C's concept > of how the two should be supported within the programming language. > Bill Wolfe, wtwolfe@hubcap.clemson.edu I see C's if as an exclusive two-case switch. If doesn't need break because fallthrough in an if would be useless -- any code common to the then and else clauses can be factored out of the if, since there are no other cases. "If", as a _special_ _case_ of switch, assumes a break; would C be better if "then" required a break to prevent fallthrough to the else? That would be a consistent way to make them similar. -- "indecipherable strangers handing out inexplicable humiliation and an unidentified army of horsemen laughing at him in his head ..." -- Douglas Adams Erik Seaberg (khan@milton.u.washington.edu) ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Invalid analogy 1990-03-03 21:11 ` Invalid analogy William Thomas Wolfe, 2847 1990-03-03 23:26 ` I Wish @ 1990-03-05 19:51 ` John F Nixon 1990-03-09 17:20 ` Tony Sanders 2 siblings, 0 replies; 60+ messages in thread From: John F Nixon @ 1990-03-05 19:51 UTC (permalink / raw) billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > [Both case and if] statements execute different sections of code > depending on the value of a controlling expression. ... the if or > case constructs ... are so closely related that one is a special case > of the other. This extreme similarity, unfortunately, does not extend > to C's concept of how the two should be supported within the ... language. I was wondering how Bill was going to defend Ada's inclusion of loop/exit :-). Clearly, it is a violation of the notion of consistency; so now we are reduced to merely consistency within "similar" constructs. I would argue that if consistency is indeed a good thing, it is worth being consistent throughout. It would be possible to design a language that is so inconsistent one would have difficulty programming in it. I claim neither C nor Ada fall in that class. I have written lots of C code, and I cannot *ever* remember leaving out a break; it is simply not confusing to anyone who understands C. I have not written much Ada; I have been confused by Ada, because I do not understand the language well. I do not understand why one cannot declare an array within a record -- one must declare an array type, then use the type within a record. Yes, I know it is good practice to declare types, but if so why does Ada allow array declarations (without type) at all? {Ada,C} can be mastered, and is a useful tool. {Ada,C} has problem areas, but is not unacceptable as a programming tool. The crucial factor is not the choice of language, but the education of the human who uses the language. The difference between the best and the average is so large that surely there is more room for improvment in education than language design. ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Invalid analogy 1990-03-03 21:11 ` Invalid analogy William Thomas Wolfe, 2847 1990-03-03 23:26 ` I Wish 1990-03-05 19:51 ` John F Nixon @ 1990-03-09 17:20 ` Tony Sanders 2 siblings, 0 replies; 60+ messages in thread From: Tony Sanders @ 1990-03-09 17:20 UTC (permalink / raw) In article <8222@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Notice: "similar flow-of-control constructs". Both the case and > the if statements execute different sections of code depending on > the value of a controlling expression. A loop is a flow-of-control > construct, but not one which is similar to the if or case constructs, > which are so closely related that one is a special case of the other. Give me a break! (sorry, couldn't resist :-) I make my living programming in C so I fail to see how evil and corrupting the C programming language is. If you make a living programming in ADA that is just fine. Someday, I might use ADA if I think it is the best language for the project I'm working on at that time. BUT! Please don't go around slamming some other language based on the fact that you think that your language of choice is the ONLY programming language that anyone should use, and then proceed to conclude that (all/some) C programmers can't possibly write good code because their language has to have a break statement at the end of a case. Take it to alt.religion.computers (where it belongs anyway) and then I'll be happy to argue day in and day out on endlessly tiny details and nuances of programming in each of the respective languages (see my followup line). Simply put: ADA is not the end all of programming languages and neither is C, both have advantages and disadvantages. Learn them and they will serve you well. -- sanders The 11th commandment: "Thou shalt use lint" For every message of the day, a new improved message will arise to overcome it. Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-28 18:57 ` Paul Snively 1990-02-28 21:35 ` Jason Coughlin @ 1990-03-01 15:33 ` Jeff Dalton 1990-03-01 21:42 ` Chuck Lins 1990-03-02 19:19 ` David F. Carlson ` (2 subsequent siblings) 4 siblings, 1 reply; 60+ messages in thread From: Jeff Dalton @ 1990-03-01 15:33 UTC (permalink / raw) In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >machismo is thus huffed and puffed up (another of my personal opinions is >that the per capita arrogance of C programmers far outweighs the per >capita arrogance of any other language-aficionado group). Except for Pascal programmers. Even Wirth has moved on by now. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-01 15:33 ` problems/risks due to programming language, stories requested Jeff Dalton @ 1990-03-01 21:42 ` Chuck Lins 0 siblings, 0 replies; 60+ messages in thread From: Chuck Lins @ 1990-03-01 21:42 UTC (permalink / raw) In article <1883@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: > >machismo is thus huffed and puffed up (another of my personal opinions is > >that the per capita arrogance of C programmers far outweighs the per > >capita arrogance of any other language-aficionado group). > >Except for Pascal programmers. Even Wirth has moved on by now. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yup. Even beyond Modula-2 to Oberon. And several colleagues at ETHZ have enhance Oberon with object-oriented extensions. -- Chuck Lins | "Exit left to funway." Apple Computer, Inc. | Internet: lins@apple.com 20525 Mariani Avenue | AppleLink: LINS Mail Stop 41-K | Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" The intersection of Apple's ideas and my ideas yields the empty set. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-28 18:57 ` Paul Snively 1990-02-28 21:35 ` Jason Coughlin 1990-03-01 15:33 ` problems/risks due to programming language, stories requested Jeff Dalton @ 1990-03-02 19:19 ` David F. Carlson 1990-03-02 22:15 ` William Thomas Wolfe, 2847 ` (2 more replies) 1990-03-02 23:01 ` problems/risks due to programming language, stories requested William J. Bouma 1990-03-14 4:46 ` Lindsay Groves 4 siblings, 3 replies; 60+ messages in thread From: David F. Carlson @ 1990-03-02 19:19 UTC (permalink / raw) In article <6960@internal.Apple.COM>, chewy@apple.com (Paul Snively) writes: > > > For what it's worth, my personal opinion is that C lends itself to > precisely the kinds of errors noted above--when does break work and when > doesn't it, and why in God's name do you need it in switch statements in > the first place, etc. What break does is *very* well defined and is no more prone to misinterpretation that any other non-linear control flow statement in any other PL. From K&R2 p 244: A9.5: iteration statement is (for, while, do)... A break statement may appear only in an iteration statement or a switch statement; control passes to the statement following the terminated statement. A multi-case switch is very handy in many situations to reduce identical treatments for similar cases. That you ask the question of the usefulness of break-per-case/multiple-cases implies that you haven't sufficient experience with the construct to judge its merits/weaknesses. Dijkstra notes that no programming language can prevent a poor programmer from creating bad programs. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 19:19 ` David F. Carlson @ 1990-03-02 22:15 ` William Thomas Wolfe, 2847 1990-03-06 10:11 ` jbaker ` (2 more replies) 1990-03-02 23:27 ` Jim Giles 1990-03-03 2:10 ` problems/risks due to programming language Karl Heuer 2 siblings, 3 replies; 60+ messages in thread From: William Thomas Wolfe, 2847 @ 1990-03-02 22:15 UTC (permalink / raw) From dave@micropen (David F. Carlson): >> For what it's worth, my personal opinion is that C lends itself to >> precisely the kinds of errors noted above--when does break work and when >> doesn't it, and why in God's name do you need it in switch statements in >> the first place, etc. > > A multi-case switch is very handy in many situations to reduce identical > treatments for similar cases. So is a multi-alternative case, as provided by Ada: case Foo is when 1 | 3 | 5 => statement1; when 2 | 4 | 6 => statement2; when others => statement3; end case; The difference is that Ada takes care of exiting the case statement for you, whereas C requires (unsafely) that you use a break to avoid being sucked into the code associated with subsequent cases. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 22:15 ` William Thomas Wolfe, 2847 @ 1990-03-06 10:11 ` jbaker 1990-03-08 15:19 ` Lou Steinberg 1990-03-09 20:13 ` problems/risks due to programming language, stories requested Tony Sanders 1990-03-15 15:31 ` problems/risks due to programming language, stories requested jaws 2 siblings, 1 reply; 60+ messages in thread From: jbaker @ 1990-03-06 10:11 UTC (permalink / raw) In article <8218@hubcap.clemson.edu> Bill Wolf writes: >From dave@micropen (David F. Carlson): >>> For what it's worth, my personal opinion is that C lends itself to >>> precisely the kinds of errors noted above--when does break work and when >>> doesn't it, and why in God's name do you need it in switch statements in >>> the first place, etc. >> >> A multi-case switch is very handy in many situations to reduce identical >> treatments for similar cases. But the real usefulness of requiring break in a switch statement is for SIMILAR treatments of similar cases, for example you may require a few assignments in one case before a more complicated computation which must be performed for several of the cases. This could be done in other languages using conditionals or multiple case statements, but it's not quite as nice. Bill Wolf writes: > So is a multi-alternative case, as provided by Ada: > > case Foo is > when 1 | 3 | 5 => > statement1; > when 2 | 4 | 6 => > statement2; > when others => > statement3; > end case; > > The difference is that Ada takes care of exiting the case statement > for you, whereas C requires (unsafely) that you use a break to avoid > being sucked into the code associated with subsequent cases. > But this is just one example of the design philosophy of C: flexibility; if the machine will let you do it (or naturally WANTS to do it), let the programmer do it the same way. Other examples of such flexibilty are the lack of type-checking, as well as allowing assignments just about anywhere. Some languages, such as Pascal, have more limitations (or less extentions) in their constructs. This usually is perfectly adequate, but for someone who writes code while thinking about how the machine will execute that code, as I do, flexibility can be useful; a small amount of speed-up, and more compact code can be the result. However, this capability has a trade-off; flexibility for follow-ability. Humans do not think like computers. We can not precisely process syntax. When code becomes too involved, it can become very difficult to follow for even the author. What could be a straight-foward program may now be a twisted mess. It becomes easy to overlook bugs that would be obvious in other languages. This is why C programmers rely heavily on a debugger. What one calls "safety" in a language, then, is just how well humans can follow a construct, without regard for its usefulness. C is not "safe," but while being quite simple and relatively low-level, it contains many flexible constucts. Sometimes, though, flexibility is present in other languages in a more "safe" fashion. For example, type conversion is available in Modula-2 IF it is explicitly done in the code. In order to use a pointer as a integer, for example, one might use: INTEGER(ch^). This flags the compiler that "we meant to do that" and warns humans that something tricky is going on. But C can be delightful to use, if you are very careful to write clear code. John Baker jbaker@gmuvax.gmu.edu Now about deciphering all those }++|#{ symbols.... ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-06 10:11 ` jbaker @ 1990-03-08 15:19 ` Lou Steinberg 1990-03-08 21:44 ` Gianfranco Ciardo 0 siblings, 1 reply; 60+ messages in thread From: Lou Steinberg @ 1990-03-08 15:19 UTC (permalink / raw) Cc: lou In article <2596@gmu90x.gmu.edu> jbaker@gmu90x.gmu.edu (jbaker) writes: > In article <8218@hubcap.clemson.edu> Bill Wolf writes: > >From dave@micropen (David F. Carlson): > >> A multi-case switch is very handy in many situations to reduce identical > >> treatments for similar cases. > > But the real usefulness of requiring break in a switch statement is for > SIMILAR treatments of similar cases, for example you may require a > few assignments in one case before a more complicated computation which > must be performed for several of the cases. ARGHHH!! That is what subroutines (and macros) are for - to handle common code. And if your language makes them too expensive, either in terms of run time or in terms of programmer effort, then THAT is an even worse problem with the language than the problems with break. -- Lou Steinberg uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou arpa: lou@cs.rutgers.edu ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-08 15:19 ` Lou Steinberg @ 1990-03-08 21:44 ` Gianfranco Ciardo 1990-03-09 16:18 ` David Kassover ` (2 more replies) 0 siblings, 3 replies; 60+ messages in thread From: Gianfranco Ciardo @ 1990-03-08 21:44 UTC (permalink / raw) In article <Mar.8.10.19.49.1990.3812@atanasoff.rutgers.edu> lou@atanasoff.rutgers.edu (Lou Steinberg) writes: > > >> A multi-case switch is very handy in many situations to reduce identical > > >> treatments for similar cases. > ARGHHH!! That is what subroutines (and macros) are for - to handle > common code. And if your language makes them too expensive, either in > terms of run time or in terms of programmer effort, then THAT is an > even worse problem with the language than the problems with break. I think you miss completely the point. Using subroutines is not going to help you make the code shorter, more compact, or less repetitious (which is not) in a case like this: switch (what_to_do) { case FIVE_THINGS: <statementA>; case FOUR_THINGS: <statementB>; case THREE_THINGS: <statementC>; case TWO_THINGS: <statementD>; case ONE_THING: <statementE>; case NOTHING: break; } ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-08 21:44 ` Gianfranco Ciardo @ 1990-03-09 16:18 ` David Kassover 1990-03-09 16:55 ` Erann Gat 1990-03-10 17:50 ` Andrew P. Mullhaupt 2 siblings, 0 replies; 60+ messages in thread From: David Kassover @ 1990-03-09 16:18 UTC (permalink / raw) In article <672@software.software.org> ciardo@software.org (Gianfranco Ciardo) writes: ... > >I think you miss completely the point. >Using subroutines is not going to help you make the code shorter, more compact, >or less repetitious (which is not) in a case like this: > > switch (what_to_do) { > case FIVE_THINGS: > <statementA>; > case FOUR_THINGS: > <statementB>; > case THREE_THINGS: > <statementC>; > case TWO_THINGS: > <statementD>; > case ONE_THING: > <statementE>; > case NOTHING: > break; > } No, but without fall through, you would write such a thing upside down. Or do something else. A couple of weeks ago I mentioned a (please bear with me) Fortran preprocessor called FLEX, which provided 4 kinds of case statement, two with fall through, two without. One instance: A particular programmer, whom I have worked with for about 10 years, rarely, if ever, used the FLEX cases-with-fallthrough. Now that he has learned C (and not recently, bTW), it seems like he goes out of his way to *USE* fall-through. I wonder why it is so difficult for language designers to provide more than one way to do things? ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-08 21:44 ` Gianfranco Ciardo 1990-03-09 16:18 ` David Kassover @ 1990-03-09 16:55 ` Erann Gat 1990-03-10 17:50 ` Andrew P. Mullhaupt 2 siblings, 0 replies; 60+ messages in thread From: Erann Gat @ 1990-03-09 16:55 UTC (permalink / raw) In article <672@software.software.org>, ciardo@software.org (Gianfranco Ciardo) writes: > Using subroutines is not going to help you make the code shorter, more compact, > or less repetitious (which is not) in a case like this: > > switch (what_to_do) { > case FIVE_THINGS: > <statementA>; > case FOUR_THINGS: > <statementB>; [etc.] > case ONE_THING: > <statementE>; > case NOTHING: > break; > } No, but writing the code like this will: if (what_to_do >= ONE_THING) <statementE>; if (what_to_do >= TWO_THINGS) <statementD>; if (what_to_do >= THREE_THINGS) <statementC>; if (what_to_do >= TWO_THINGS) <statementB>; if (what_to_do >= ONE_THING) <statementA>; If you wish to quibble over my use of inequalities, replace them with a disjunction of equalities. Erann Gat gat@robotics.jpl.nasa.gov ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-08 21:44 ` Gianfranco Ciardo 1990-03-09 16:18 ` David Kassover 1990-03-09 16:55 ` Erann Gat @ 1990-03-10 17:50 ` Andrew P. Mullhaupt 1990-03-12 4:06 ` Peter da Silva ` (2 more replies) 2 siblings, 3 replies; 60+ messages in thread From: Andrew P. Mullhaupt @ 1990-03-10 17:50 UTC (permalink / raw) > or less repetitious (which is not) in a case like this: > > switch (what_to_do) { > case FIVE_THINGS: ... This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c, right(?). The fistfight over bill wolfe's complaints about C should stay in comp.lang.c. If anyone wants to complain about Pascal, then put it in here. BTW - fall through and the 'double duty' break keyword are definitely examples of C flaws. If you must, flame me, but in comp.lang.c, (OK?) Later, Andrew Mullhaupt ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-10 17:50 ` Andrew P. Mullhaupt @ 1990-03-12 4:06 ` Peter da Silva 1990-03-12 16:58 ` Jeff Clark 1990-03-12 20:20 ` Proposal comp.lang.jihad (was Re: problems/risks due to blah etc.) What`s in a name? 2 siblings, 0 replies; 60+ messages in thread From: Peter da Silva @ 1990-03-12 4:06 UTC (permalink / raw) > This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c, > right(?). No, it doesn't belong in comp.lang.c either. Language lawyers should hold their court in comp.lang.misc or alt.religion.computers. this thread may have some slight relevence to comp.software-eng. It doesn't belong in any of comp.lang.{c,ada}... and even less in comp.lang.{lisp,modula2,pascal}. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-10 17:50 ` Andrew P. Mullhaupt 1990-03-12 4:06 ` Peter da Silva @ 1990-03-12 16:58 ` Jeff Clark 1990-03-12 20:20 ` Proposal comp.lang.jihad (was Re: problems/risks due to blah etc.) What`s in a name? 2 siblings, 0 replies; 60+ messages in thread From: Jeff Clark @ 1990-03-12 16:58 UTC (permalink / raw) In article <775@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes: This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c, Actually, I don't think it belongs in any of these groups. This "discussion" seems to have no end and no reasonable resolution since the antagonists arguments are based on personal opinions, preferences, and emotions. I've not seen anyone quote studies of the influence of "human factors" in programming language design nor has any one proposed such a study as a useful outcome of this recent flame war (although I must admit I'm wearing out the 'n' key on my workstation). comp.lang.religious-wars anyone? Jeff Clark Honeywell Systems and Research Center Minneapolis, MN inet: jclark@src.honeywell.com tel: 612-782-7347 uucp: jclark@srcsip.UUCP fax: 612-782-7438 DISCLAIMER: If you think I speak for my employer, you need serious help ... ^ permalink raw reply [flat|nested] 60+ messages in thread
* Proposal comp.lang.jihad (was Re: problems/risks due to blah etc.) 1990-03-10 17:50 ` Andrew P. Mullhaupt 1990-03-12 4:06 ` Peter da Silva 1990-03-12 16:58 ` Jeff Clark @ 1990-03-12 20:20 ` What`s in a name? 2 siblings, 0 replies; 60+ messages in thread From: What`s in a name? @ 1990-03-12 20:20 UTC (permalink / raw) In article <775@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes: >This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c, >right(?). The fistfight over bill wolfe's complaints about C should >stay in comp.lang.c. If anyone wants to complain about Pascal, then No. People who want to discuss C can do so in comp.lang.c. The fistfight over Bill Wolfe, and his comments can go into comp.lang.jihad. I imagine that these other groups would like to see a number of threads piped into said new newsgroup as well... Anybody want to take this one seriously? --mike -- Mic3hael Sullivan, Society for the Incurably Pompous -*-*-*-*- I'd hate to write a requiem and then not die. -- Jean Cardinale ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 22:15 ` William Thomas Wolfe, 2847 1990-03-06 10:11 ` jbaker @ 1990-03-09 20:13 ` Tony Sanders 1990-03-13 22:11 ` Erland Sommarskog 1990-03-19 1:01 ` Ada vs C, objectivity requested Lucio de Re 1990-03-15 15:31 ` problems/risks due to programming language, stories requested jaws 2 siblings, 2 replies; 60+ messages in thread From: Tony Sanders @ 1990-03-09 20:13 UTC (permalink / raw) In article <8218@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > So is a multi-alternative case, as provided by Ada: How do you do this in ADA? switch(n) { case 0: count++; case 1: ocount++; case 2: printf("%d %d\n",count,ocount); break; default: printf("unknown n\n"); break; } See how I left out the breaks on purpose. In ADA you wouldn't be able to do this without duplicating either the case-expression (they aren't always simple numbers) or the statements. -- sanders The 11th commandment: "Thou shalt use lint" For every message of the day, a new improved message will arise to overcome it. Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-09 20:13 ` problems/risks due to programming language, stories requested Tony Sanders @ 1990-03-13 22:11 ` Erland Sommarskog 1990-03-19 1:01 ` Ada vs C, objectivity requested Lucio de Re 1 sibling, 0 replies; 60+ messages in thread From: Erland Sommarskog @ 1990-03-13 22:11 UTC (permalink / raw) I tried thrice mailing this guy, including the path(!) he gave in his signature. Couldn't IBM afford to be better connected? Tony Sanders (sanders@sanders.austin.ibm.com) writes: >How do you do this in ADA? > > switch(n) { > case 0: > count++; > case 1: > ocount++; > case 2: > printf("%d %d\n",count,ocount); > break; > default: > printf("unknown n\n"); > break; > } > >See how I left out the breaks on purpose. Cross you heart, how often in practical programming do you write such code? And how often compared to normal switch statements where an easily elided break would introduce a simple bug? It might be that I never program in C, but I have never felt the need for a fall-through. Also, it seem more frequent that I first want to execute some common code and then split the cases further. In this case C's fall-throughs help you none. In Ada (please note, it's not all-capital) I would probably have written the above as: IF N = 0 THEN Count := Count + 1; END IF; IF N IN 0..1 THEN OCount := OCount + 1; END IF; IF N IN 0..2 THEN Put(Count, 10); Put(OCount, 10); New_line; ELSE Put_line("Unknown."); END IF; With a one-line statement for N = 2, I might have chosen to repeat some lines of code, if the CASE statement better had illustrated the problem. (And I would probably have made the same arrangements in C.) -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se ^ permalink raw reply [flat|nested] 60+ messages in thread
* Ada vs C, objectivity requested 1990-03-09 20:13 ` problems/risks due to programming language, stories requested Tony Sanders 1990-03-13 22:11 ` Erland Sommarskog @ 1990-03-19 1:01 ` Lucio de Re 1990-03-26 20:37 ` Karl Heuer 1 sibling, 1 reply; 60+ messages in thread From: Lucio de Re @ 1990-03-19 1:01 UTC (permalink / raw) In article <1771@awdprime.UUCP>, sanders@sanders.austin.ibm.com (Tony Sanders) writes: > In article <8218@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > So is a multi-alternative case, as provided by Ada: > How do you do this in ADA? > > ... silly code omitted ... > > See how I left out the breaks on purpose. > > In ADA you wouldn't be able to do this without duplicating either the > case-expression (they aren't always simple numbers) or the statements. > I don't think that's a serious drawback, unless you have a very limited amount of memory. I like the facility that as you point out does not exist in ADA, but I have got around the same lack in Pascal and Modula 2 without any great identity crisis. And I have forgotten the break on occasion, but I have learnt to spot the error quite quickly, even though it is becoming more and more scarce in my code (I generally enter all the case clauses, then separate them with break's when using VI; in BRIEF, I would modify the macros to do this for me). It really is silly to knock a language on the basis of certain constructs. Good programmers will use ADA or C successfully and bad programmers will screw up in ADA or in C. We are not all or always good programmers and we need to be alert to different possible failings in the two languages. Can Bill Wolfe vouch for ADA having no failings? And, as justification for my satisfaction with C not putting too many checks in my programming path, I have the following similitude: I normally ride a motorcycle at speeds in excess both of speed limits and of traffic speeds. I have to be very alert to survive, as automobile drivers seem utterly oblivious of my presence. If I travel more slowly, my attention span decreases and I become less alert. Also, not being insured, I find I am more conscious of my vulnerability than I was when I was insured. Similarly, in C I try very hard to avoid its pitfalls. I follow this thread because of the pitfalls that have been brought up (none that I wasn't aware of, yet) and I regret my lack of ADA knowledge, at least to some degree. In Modula 2 I too often let the compiler pick up my distractions, which means that semantic errors are more likely to have crept in. Is ADA similarly soporific; if so give me C, and programmers under my supervision will program in Modula 2 because I know the quality of the code I produce and I also know the type of clever (read illegible, often wrong or at the very least incapable of coping with special cases) code that less disciplined programmers can produce in C. But it is an issue of survival. Bad C programmers will eventually hang themselves, the same way that bad motorcycling would have killed or crippled me long ago (and has killed and crippled others) had I indulged in it. C requires self-discipline where Modula 2 and ADA force discipline on you. The result is that C programmers have more freedom, the price for which is one of greater alertness or the possibility that the compiler won't pick up what might be a simple mistake, while ADA and Modula 2 programmers have to be devious to do what they may have to do that the language inhibits. And further, ADA suffers from a very bad disease: committeetis. By the time a committee completes a definition, it cannot possibly have included the latest developments in language design. Worse, once the definition is finalised, implementation stretches further and the language is (in at least some facets) obsolete by the time the implementation is complete. To quote an example from the other side, the ANSI standard for C has been superceded, prior to publication by the availability of C++ compilers. Ironic? The standard has its place, but it would be sad to stifle further development in C++ by promulgating a standard that freezes it at this stage, for example. We are learning so much, it is impossible to encompass all GOOD language features in any one committee generated standard (thank goodness!). Take another point. The "0b" prefix Walter Bright added to provide binary number representation is an obvious extension to C. The ANSI committee did not consider it, nor did Stroustrup. Well, I like it and I use it, and I would like it incorporated into the ANSI standard. Certainly I would hate to lose it because some committee states that its implementation invalidates my compiler's compliance with the standard. ---------------------------------------------------------------------- I used to design nuclear reactors and you should see the code that engineers and scientists come up with. Yuuuck! Spaghetti everywhere. -------------------------------------------------- (Kenneth L Moore) - Lucio de Re ...uunet!ddsw1!olsa99!proxima!lucio -------------------------------------------------------- lucio@proxima Disclaimer: He must have been joking! ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Ada vs C, objectivity requested 1990-03-19 1:01 ` Ada vs C, objectivity requested Lucio de Re @ 1990-03-26 20:37 ` Karl Heuer 0 siblings, 0 replies; 60+ messages in thread From: Karl Heuer @ 1990-03-26 20:37 UTC (permalink / raw) This subthread is C-specific. I am redirecting followups to comp.lang.c. \f In article <567@proxima.UUCP> lucio@proxima.UUCP (Lucio de Re) writes: >Take another point. The "0b" prefix Walter Bright added to provide >binary number representation is an obvious extension to C. The ANSI >committee did not consider it... It *was* considered, but rejected. I suspect the response was "Insufficient utility; Does not address a major deficiency; No established current practice" or something like that. >Well, I like it and I use it, and I would like it incorporated into the ANSI >standard. No problem. Campaign to have it added to gcc; hint to your other vendors that you like the feature. If it's current practice when the next time around, it has a much better chance of making it into C-2000. >Certainly I would hate to lose it because some committee states that its >implementation invalidates my compiler's compliance with the standard. The feature doesn't break any existing code. At worst, it requires a warning diagnostic when the compiler is run in strictly pedantic ANSI mode. The fact that ANSI doesn't support it is not an excuse for not providing it. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 22:15 ` William Thomas Wolfe, 2847 1990-03-06 10:11 ` jbaker 1990-03-09 20:13 ` problems/risks due to programming language, stories requested Tony Sanders @ 1990-03-15 15:31 ` jaws 2 siblings, 0 replies; 60+ messages in thread From: jaws @ 1990-03-15 15:31 UTC (permalink / raw) Mr Wolf: C allows you to combine cases that have portions of similiar code but may have extra lead in code for a specific case: switch var: case A: /* do stuff only case A needs */ case B: /* do stuff case A and case B need done */ . . break; /* rest of switch */ this construct in impossible to do cleanly in almost every language I have ever seem, especially ADA. This kind flexiability is what makes C so powerfull, and dangerous. You have know what you are doing to do it. [ Jeff Wilson :: jaws@chibacity.austin.ibm.com ] [ Consultant from Pencom, Inc. at Human Factors, AWD, IBM Austin. ] [My comments are wholly my own and as such take them for what they are worth. ] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 19:19 ` David F. Carlson 1990-03-02 22:15 ` William Thomas Wolfe, 2847 @ 1990-03-02 23:27 ` Jim Giles 1990-03-03 2:23 ` Vincent Manis 1990-03-03 2:10 ` problems/risks due to programming language Karl Heuer 2 siblings, 1 reply; 60+ messages in thread From: Jim Giles @ 1990-03-02 23:27 UTC (permalink / raw) From article <1004@micropen>, by dave@micropen (David F. Carlson): > [... explicit breaks in the C switch construct ...] > Dijkstra notes that no programming language can prevent a poor programmer from > creating bad programs. He also notes that the choice of programming language can have a strong effect on the quality of the resulting code. (His indictment of PL/I as being similar to flying a widebodied jet with all the windows taped over and no labels on the thousands of controls was quite apropos.) This effect of the language choice is mainly psychological - and it CAN be overcome (which is the main thrust of many of Dijkstra's works). But, be honest, how many programmers do you know who _really_ construct their programs abstractly _before_ even selecting their implementation language? This is the proper way (a' la Dijkstra) to make sure the you aren't negatively impacted by the language - you select the proper language for the job at hand - you don't mangle the job to fit the language. Dijkstra's statement, while true, should not be used to excuse poorly designed language features (as you are trying to do). A better design for C would have been _not_ to require breaks after each case and to provide some other syntax for the representation of multiple choices on the same case. It's easy to see these kinds of design errors in retrospect (C _is_ nearly 20 years old you know). J. Giles ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-03-02 23:27 ` Jim Giles @ 1990-03-03 2:23 ` Vincent Manis 0 siblings, 0 replies; 60+ messages in thread From: Vincent Manis @ 1990-03-03 2:23 UTC (permalink / raw) I might note that B's syntax, and hence C's syntax, was a definite *dis*improvement [sic] over that of its predecessor, BCPL. I would in fact post an article saying exactly that, except for the fact that this entire thread most certainly belongs somewhere, but not in comp.lang.scheme. Would you please edit the Newsgroups: line in further articles on this subject? -- \ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and \ Department of Computer Science literary excellence cannot coexist." /\ University of British Columbia -- A. Trevor Hodge / \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language 1990-03-02 19:19 ` David F. Carlson 1990-03-02 22:15 ` William Thomas Wolfe, 2847 1990-03-02 23:27 ` Jim Giles @ 1990-03-03 2:10 ` Karl Heuer 2 siblings, 0 replies; 60+ messages in thread From: Karl Heuer @ 1990-03-03 2:10 UTC (permalink / raw) In article <1004@micropen> dave@micropen (David F. Carlson) writes: >What break does is *very* well defined and is no more prone to >misinterpretation that any other non-linear control flow statement ... Yes, it's well defined, but what it's defined to do is bad. For a formal treatment of the above statement, I refer you to my article <16039@haddock.ima.isc.com>, posted to comp.lang.misc (also .c and .ada) with this same title. I haven't seen any rebuttals yet. >A multi-case switch is very handy in many situations ... Yeah. I wish C had this feature, instead of simulating it with fallthrough. >That you ask the question of the usefulness of break-per-case/multiple-cases >implies that you haven't sufficient experience with the construct to judge >its merits/weaknesses. I don't know about the person you were addressing, but I think I've had sufficient experience with it. I certainly question its usefulness in comparison to something reasonable, like the language I described in my other article. In fact, even if you insist that the comparison must be between C and plain-C-without-break-switch, I think I'd still go for the latter. I believe the benefit of not requiring an overloaded keyword to do a break-switch exceeds the cost of having to use a goto to merge related cases. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-28 18:57 ` Paul Snively ` (2 preceding siblings ...) 1990-03-02 19:19 ` David F. Carlson @ 1990-03-02 23:01 ` William J. Bouma 1990-03-14 4:46 ` Lindsay Groves 4 siblings, 0 replies; 60+ messages in thread From: William J. Bouma @ 1990-03-02 23:01 UTC (permalink / raw) In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >We all know C programmers whose >machismo is thus huffed and puffed up (another of my personal opinions is >that the per capita arrogance of C programmers far outweighs the per >capita arrogance of any other language-aficionado group). Oh, really! I can tell you have never met any FORTH programmers. >Well, I hate to say it, but it's extremely unlikely that such an error >would have been made in Pascal, since Pascal doesn't require you to >explicitly break from case...of constructs. Well isn't that special! The way I see it, C gives you the flexibility to not break if you don't want to, where PASCAL restricts you to break. >Before the flames start, Too late! > let me just add: no, I don't necessarily prefer Pascal over C for all tasks. The only place I can see to prefer PASCAL over C is a beginner programming class. Isn't PASCAL usually thrown out along with the diapers? -- Bill <bouma@cs.purdue.edu> | And don't forget my dog... "Astronomy" -- BOC ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: problems/risks due to programming language, stories requested 1990-02-28 18:57 ` Paul Snively ` (3 preceding siblings ...) 1990-03-02 23:01 ` problems/risks due to programming language, stories requested William J. Bouma @ 1990-03-14 4:46 ` Lindsay Groves 4 siblings, 0 replies; 60+ messages in thread From: Lindsay Groves @ 1990-03-14 4:46 UTC (permalink / raw) In article <1004@micropen>, dave@micropen (David F. Carlson) writes: > What break does is *very* well defined and is no more prone to misinterpretation > that any other non-linear control flow statement in any other PL. A number of people in this discussion (which I haven't reached the end of yet!) have said things like this, and appear to be suggesting that because something is well defined there is no excuse for anyone misusing it. I disagree with that and also with the second part of this statement. There are languages in which any kind of exit has to explicitly name the construct to be exitted -- so there is no possiblity of consfusion about which construct the exit/break/etc. applies to. > A multi-case switch is very handy in many situations to reduce identical > treatments for similar cases. That you ask the question of the usefulness > of break-per-case/multiple-cases implies that you haven't sufficient experience > with the construct to judge its merits/weaknesses. > > Dijkstra notes that no programming language can prevent a poor programmer from > creating bad programs. So why aren't we all still using FORTRAN (or some older dialect)? Why did we all think that unlabelled CASE statements (as in Algol-W and Burroughs Algol) were a big improvement over computed GOTOs in FORTRAN (which is basically what the switch in C is), or that the labelled CASE statement (as in Pascal) was a big improvement over that? Maybe the whole of the last 30 years of work in programming language design has been a dream!!! Lindsay Groves ^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~1990-03-26 20:37 UTC | newest] Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1990-02-20 22:28 problems/risks due to programming language, stories requested Gerald Baumgartner 1990-02-21 16:49 ` Richard A Hammond 1990-02-21 20:15 ` problems/risks due to programming language William Thomas Wolfe, 2847 1990-02-21 22:49 ` Richard A Hammond 1990-02-21 23:14 ` John F Nixon 1990-02-22 5:39 ` Scott MacHaffie 1990-02-22 20:13 ` William Thomas Wolfe, 2847 1990-02-23 17:32 ` Richard A Hammond 1990-02-25 20:23 ` David Kassover 1990-02-22 20:48 ` Jeff Lawhorn 1990-02-23 2:00 ` Douglas Miller 1990-02-22 16:05 ` Dan L. Pierson 1990-02-22 20:28 ` David Kassover 1990-02-24 19:52 ` Erland Sommarskog 1990-02-23 17:45 ` Mike Harrison 1990-02-27 2:02 ` Douglas Miller 1990-02-22 18:28 ` Mike Percy 1990-02-23 2:09 ` Douglas Miller 1990-02-22 0:25 ` problems/risks due to programming language, stories requested David Kassover 1990-02-22 3:42 ` Richard A Hammond 1990-02-22 16:08 ` David Kassover 1990-02-22 16:21 ` David Kassover 1990-02-23 18:11 ` Thomas Vachuska 1990-02-24 0:13 ` Mark Brader 1990-02-27 19:30 ` Bill Leonard 1990-02-28 18:57 ` Paul Snively 1990-02-28 21:35 ` Jason Coughlin 1990-03-01 19:00 ` Barry Margolin 1990-03-02 13:31 ` Richard A Hammond 1990-03-02 19:26 ` William Thomas Wolfe, 2847 1990-03-02 22:19 ` Richard A Hammond 1990-03-06 21:54 ` John Boone 1990-03-03 20:18 ` Charles E Eaker 1990-03-03 21:11 ` Invalid analogy William Thomas Wolfe, 2847 1990-03-03 23:26 ` I Wish 1990-03-05 19:51 ` John F Nixon 1990-03-09 17:20 ` Tony Sanders 1990-03-01 15:33 ` problems/risks due to programming language, stories requested Jeff Dalton 1990-03-01 21:42 ` Chuck Lins 1990-03-02 19:19 ` David F. Carlson 1990-03-02 22:15 ` William Thomas Wolfe, 2847 1990-03-06 10:11 ` jbaker 1990-03-08 15:19 ` Lou Steinberg 1990-03-08 21:44 ` Gianfranco Ciardo 1990-03-09 16:18 ` David Kassover 1990-03-09 16:55 ` Erann Gat 1990-03-10 17:50 ` Andrew P. Mullhaupt 1990-03-12 4:06 ` Peter da Silva 1990-03-12 16:58 ` Jeff Clark 1990-03-12 20:20 ` Proposal comp.lang.jihad (was Re: problems/risks due to blah etc.) What`s in a name? 1990-03-09 20:13 ` problems/risks due to programming language, stories requested Tony Sanders 1990-03-13 22:11 ` Erland Sommarskog 1990-03-19 1:01 ` Ada vs C, objectivity requested Lucio de Re 1990-03-26 20:37 ` Karl Heuer 1990-03-15 15:31 ` problems/risks due to programming language, stories requested jaws 1990-03-02 23:27 ` Jim Giles 1990-03-03 2:23 ` Vincent Manis 1990-03-03 2:10 ` problems/risks due to programming language Karl Heuer 1990-03-02 23:01 ` problems/risks due to programming language, stories requested William J. Bouma 1990-03-14 4:46 ` Lindsay Groves
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox