billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/01/90)
From marick@m.cs.uiuc.edu: > There are two assertions in Bill Wolfe's message: > 1. The C community releases an unacceptable number of errors. > 2. The C language is at least partly the *cause* of those errors. 3. Many members of the C community exhibit an unprofessional and irresponsible attitude regarding defect control and especially defect prevention. 4. Those members of the C community who ARE responsible professionals are apparently not taking significant actions to raise the level of software engineering professionalism within the C community. The unsafe constructs within C are themselves sufficient evidence to conclude that the C community, by choosing to use a language which has many highly unsafe constructs and an almost total disregard for error prevention, does not hold error prevention in sufficiently high regard; the failure of a password security system because no boundary checks were done on the length of the password (whereupon the intruder purposely supplied a double-length password and thereby ensured that the left and right sections of the password-validating data structure were compatible), and similar cases demonstrate that the C language poses a serious obstacle to the development of defect-minimal software. For the cost of simply the recent national AT&T crash, I'd be willing to conjecture that all of AT&T's software developers could have been trained in software engineering concepts and the Ada language, and supplied with Ada compilers as well. The comments found in the Unix man pages I cited have been there for at least a decade, apparently going unchallenged by the rest of the C community. This is despite the fact that the growth of C has been widely attributed to the Unix operating system being given away to so many universities -- if this attribution is correct, then Unix is also responsible for helping to create the widespread attitude within the C community that defects are to be treated casually. It is entirely true that other language communities (BASIC, COBOL, etc.) have problems along these lines which are arguably worse than those which are clearly associated with the C community. On the other hand, there are other language communities which are doing a considerably better job of spreading software engineering concepts and providing linguistic support for their application (Ada, Eiffel, etc.). The challenge for the C community is to join the language communities which are doing a good job in these respects, as opposed to holding its existing reputation as a community which contains an extremely high percentage of those who regard themselves as hackers, and whose products repeatedly make national headlines with their spectacular failures. Since C is a language which provides little or no support for defect prevention, one would expect that the C community would naturally compensate by being extremely careful about always applying the very best software engineering practices. Unfortunately, I don't think even the most dedicated C-backers would attempt to claim that this is presently the case. Bill Wolfe, wtwolfe@hubcap.clemson.edu
ekrell@ulysses.att.com (Eduardo Krell) (03/02/90)
In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > For the cost of simply > the recent national AT&T crash, I'd be willing to conjecture that all of > AT&T's software developers could have been trained in software engineering > concepts and the Ada language, and supplied with Ada compilers as well. And what makes you think the network wouldn't have crashed if the software had been written in Ada (you seem to imply this)? Do you know the details of the cause of the crash?. You're just speculating that it was related to the "unsafe" nature of C. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
peter@ficc.uu.net (Peter da Silva) (03/02/90)
In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Many members of the C community exhibit an unprofessional and > irresponsible attitude regarding defect control and especially > defect prevention. Many members of the programming community as a whole exhibit an unprofessional and irresponsible attitude regarding defect control and expecially defect prevention. C happens to be the most popular language on a wide range of hardware, by the chance that it happens to be well adapted to writing reasonably portable and reasonably efficient programs, without being particularly hard to implement or having particularly many functional shortfalls. Most other system programming languages are either harder to implement (such as ADA), do not fit well into the normal program linking model (such as Modula), or are simply inadequate without nonstandard extensions (most dialects of Pascal). Thus, simply by statistics one could predict that a large number of programs written in C are likely to contain major bugs. There are a large number of programs written in C, period. Would you care to address the confusing and dangerous deficiencies in the ADA language: operator overloading and the use of rendezvous for interprocess communication, for example? Have you read C. A. R. Hoare's Turing Award lecture, "The Emperor's New Clothes"? -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
mcilree@mrsvr.UUCP (Robert McIlree) (03/02/90)
From article <12643@ulysses.att.com>, by ekrell@ulysses.att.com (Eduardo Krell): > In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >> For the cost of simply >> the recent national AT&T crash, I'd be willing to conjecture that all of >> AT&T's software developers could have been trained in software engineering >> concepts and the Ada language, and supplied with Ada compilers as well. > > And what makes you think the network wouldn't have crashed if the software > had been written in Ada (you seem to imply this)? Do you know the details > of the cause of the crash?. You're just speculating that it was related > to the "unsafe" nature of C. Let me add something to Eduardo's comments: The vast majority, if not all, of AT&T's developers *are* trained in software engineering concepts in-house. I know. I used to work at Bell Labs. I learned more about software engineering, methodologies, and development lifecycles from that environment than in any other place I've worked, before or since. At a minimum, that training was far better than what it appears you have learned at Duke (bastion of CS that it is), Mr. Wolfe - if simply by judging the quality of the school from your postings of absolute conjecture and crap. Oh, is the above a little unfair? Well, so is your indictment of C without: a) facts and b) experience. Programming languages are not the root of all evil. Failures are also linked to inadequate analysis, lack of testing, poor development environments, and documentation problems, to name a few. I'll reiterate to you that systems are not, and never are 100% reliable. The AT&T crash was bound to happen sooner or later, but not because the software was coded in C. Things like software complexity and network topology issues come to mind immediately, with nothing at all to do with language specificity. Perhaps you can take the time to put down the Ada manual and learn something about these topics, because the lack of depth in your pronouncements is showing. Unfortunately, very little of the drivel you have posted in these forums touch on non-coding parts of the development lifecycle. You, for one reason or another, simply ignore them and keep thumping your Ada bible like some evangelical idiot. Ignorance of those topics doesn't make you a software engineer. At best, it makes you a coder. And coders, Mr. Wolfe, are a dime-a-dozen. So are religous wars on which programming languages are "the best." If you're going to indict the software engineering community for your percieved attrocities and ignorace, perhaps you could start at the top - like in requirements and management issues, which is where the majority of the problems start. Blasting Joe-C-Programmer for the world's ills is just so much hot air - which is to be expected from you, I'd reckon. Bob McIlree
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/02/90)
From ekrell@ulysses.att.com (Eduardo Krell): > And what makes you think the network wouldn't have crashed if the software > had been written in Ada (you seem to imply this)? Do you know the details > of the cause of the crash?. The crash apparently was caused by a programmer who used a "break" within an if (which itself was within a switch) for the purpose of exiting the if; the real result was to exit the switch instead. If C provided a case statement rather than a switch..break system, then the error would most likely have been prevented. See the recent discussion of this topic in comp.lang.c. Bill Wolfe, wtwolfe@hubcap.clemson.edu
stevee@ism780c.isc.com (Steve Ellingson) (03/02/90)
C is a language for consenting adults, Pascal is a language for naughty children, and Ada is a language for criminals! Steve
jacob@gore.com (Jacob Gore) (03/02/90)
/ comp.lang.c / billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) / Mar 1, 1990 / > The [AT&T long distance netrowk] crash apparently was caused by a > programmer who used a "break" > within an if (which itself was within a switch) for the purpose of > exiting the if; the real result was to exit the switch instead. So what else is new? In the following Ada code the "exit" will exit the loop instead of the 'if' statement: loop ... if ... then ... exit; end if; ... end loop; In C, 'break' exits switches and loops. Not ifs. > If C provided a case statement rather than a switch..break system, then > the error would most likely have been prevented. unless the whole thing was enclosed in a loop, which would be exited instead of the 'if'. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
machaffi@fred.cs.washington.edu (Scott MacHaffie) (03/02/90)
In article <8192@hubcap.clemson.edu% billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
% The unsafe constructs within C are themselves sufficient evidence to
% conclude that the C community, by choosing to use a language which has
% many highly unsafe constructs and an almost total disregard for error
% prevention, does not hold error prevention in sufficiently high regard;
paraphrase:
I can't write code worth a damn, so no one else can either.
% the failure of a password security system because no boundary checks
% were done on the length of the password (whereupon the intruder purposely
% supplied a double-length password and thereby ensured that the left and
% right sections of the password-validating data structure were compatible),
% and similar cases demonstrate that the C language poses a serious obstacle
% to the development of defect-minimal software. For the cost of simply
paraphrase:
Someone else fucked up (or I made it up, one of the two) so I can use
that as an argument.
% the recent national AT&T crash, I'd be willing to conjecture that all of
% AT&T's software developers could have been trained in software engineering
% concepts and the Ada language, and supplied with Ada compilers as well.
paraphrase:
ADA is perfect. No one has ever written a piece of ADA code with bugs in it.
If AT&T had used ADA their code would have worked without being tested.
% The comments found in the Unix man pages I cited have been there for
% at least a decade, apparently going unchallenged by the rest of the
% C community. This is despite the fact that the growth of C has been
paraphrase:
Unix had bugs TEN WHOLE YEARS ago!
% widely attributed to the Unix operating system being given away to
% so many universities -- if this attribution is correct, then Unix is
% also responsible for helping to create the widespread attitude within
% the C community that defects are to be treated casually.
paraphrase:
Hey, now I can try to flame Unix, too! Maybe I should cross-post to comp.unix
-- I'm sure they would appreciate knowing that they can't do any software
engineering with their systems.
% It is entirely true that other language communities (BASIC, COBOL, etc.)
% have problems along these lines which are arguably worse than those which
% are clearly associated with the C community. On the other hand, there are
paraphrase:
What the fuck, I can try to flame EVERYONE. After all, I am perfect.
% other language communities which are doing a considerably better job of
% spreading software engineering concepts and providing linguistic support
% for their application (Ada, Eiffel, etc.). The challenge for the C
paraphrase:
If I say it enough, maybe someone will believe me.
% community is to join the language communities which are doing a good
% job in these respects, as opposed to holding its existing reputation
% as a community which contains an extremely high percentage of those who
% regard themselves as hackers, and whose products repeatedly make national
% headlines with their spectacular failures. Since C is a language which
paraphrase:
Look, I have made-up statistics to prove my point! And I can also ignore
counter-examples!
% provides little or no support for defect prevention, one would expect
% that the C community would naturally compensate by being extremely
% careful about always applying the very best software engineering
% practices. Unfortunately, I don't think even the most dedicated
% C-backers would attempt to claim that this is presently the case.
paraphrase:
I'm not a C programmer, but I can damn well speak for all of them.
jseidman@jarthur.Claremont.EDU (James Seidman) (03/02/90)
In article <470008@gore.com> jacob@gore.com (Jacob Gore) writes: >/ comp.lang.c / billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu >(William Thomas Wolfe, 2847 ) / Mar 1, 1990 / >> The [AT&T long distance netrowk] crash apparently was caused by a >> programmer who used a "break" >> within an if (which itself was within a switch) for the purpose of >> exiting the if; the real result was to exit the switch instead. > >So what else is new? In the following Ada code the "exit" will exit the >loop instead of the 'if' statement: >[Exactly analogous Ada example deleted] >In C, 'break' exits switches and loops. Not ifs. Of course, part of Bill's point is that anyone who is programming in Ada will be trained in software engineering and therefore will not make mistakes. On the other hand we C programmers are all people who just graduated from high school and are writing code without any formal training. He also has the point that if Unix was rewritten in Ada then it would have no security holes. Similarly, if the units(1) utility were written in Ada it would automatically update currency values. I might point out, however, that there is at least one Ada compiler in existence which is itself written in C, and therefore you should be very wary when using an Ada compiler in case it's that one. Now if only the Ada compiler was written in Ada instead... By the way, has anybody compared speeds of Ada and C implementations? I don't know about other platforms, but on our VMS system an Ada program which simply prints "Hello World!" on the screen takes eight times longer to compile than a similar C program, and the executable is 11 times longer in length. The execution time appears to be about three times slower as well. I really think it's time for the Ada community to clean up its act and get some faster compilers. As a parting shot, I will end this post with a list of all of the utilities on our VMS *and* Unix systems which are written in Ada: ----- beginning of list ----- ----- end of list ----- Fortunately, thanks to programmers like Bill Wolfe, they are all bug free. -- ------------------------------------------------------------------------------- Jim Seidman, Harvey Mudd College, Claremont, CA 91711. (714) 621-8000 x2026 DISCLAIMER: I don't even know if these are opinions, let alone those of anyone other than me.
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (03/03/90)
From article <8201@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > The crash apparently was caused by a programmer who used a "break" > within an if (which itself was within a switch) for the purpose of > exiting the if; the real result was to exit the switch instead. If > C provided a case statement rather than a switch..break system, then > the error would most likely have been prevented. The problem was obviously the ignorance of the programmer. Blaming the fruits of that ignorance on the language in which he/she was programming is a comperable error. The syntax of the switch construct and the functionality of break have been well defined for well over a decade. It would be much more constructive, and more appropriate to software-eng, to observe that such a primitive error would have been caught and fixed, before it had a chance to do any damage, if the organization in which the routine was developed observed the practice of code reviews. This might not be a popular answer in some circles, but it is the only competant answer to this problem. Chris Prael
frankw@hpcvra.CV.HP.COM (Frank Wales) (03/03/90)
In some article (William Thomas Wolfe, 2847 ) billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From ekrell@ulysses.att.com (Eduardo Krell): >> And what makes you think the network wouldn't have crashed if the software >> had been written in Ada (you seem to imply this)? Do you know the details >> of the cause of the crash?. > The crash apparently was caused by a programmer who used a "break" > within an if (which itself was within a switch) for the purpose of > exiting the if; the real result was to exit the switch instead. If > C provided a case statement rather than a switch..break system, then > the error would most likely have been prevented. Well, actually, the crash was caused by software which didn't work right. Deducing the reasons behind this are an interesting academic exercise, and may indeed point to language design problems, both for C specifically and other languages in general, but for me at least, I just note the problem as a potential difficulty in future programming, and get on with the job. I certainly don't slap myself on the forehead, exclaiming: "What a crock C is! From now on, I'm going to use <your favourite language> instead!" Useful tools are hard to come by, and take time to master. I need a better reason than nit-pickety details to discard one and learn another. If someone came to me and explained a bug in a piece of software he'd written with: "well, if the semantics of C were different, it would have worked okay," he would be the proud owner of what my father would have called 'a swift kick up the arse'. Where I come from, software in *any* language is supposed to be tested. If you feel the need to put code in to handle something, you test that code. If it isn't important to make sure the code works right, you don't put it in. And this is *not* a C issue, this is a software development issue. You can write broken software in any language, regardless of its syntax, semantics or size (they tell me size doesn't matter, but...). Whatever the reason for the defects, putting software in service without fixing them is wrong. Can you tell me, Bill, that you *know* that if the semantics of C were different, that no other problems would have arisen as a consequence of the difference? [Note for language zealots: I am not attempting to defend the design of C here; it has its deficiencies, but it is still a useful language for many types of work. I believe it is the most pragmatic language of its time, and that the most pragmatic language of today is Eiffel. I don't think there is *any* language in which one can do useful work that doesn't also have cognitive pitfalls somewhere, including Ada. I'd like to see the language which guarantees working software without testing. I think it would give me a good excuse to shout "yippee!" for once.] -- Frank Wales, Guest of HP Corvallis, [frank@zen.co.uk||frankw@hpcvdq.cv.hp.com] Zengrange Ltd., Greenfield Road., LEEDS, England, LS9 8DB. (+1)-503-750-3086
sanders@sanders.austin.ibm.com (Tony Sanders) (03/06/90)
In addition to the multitudinous messages already written on this subject I would like to add a couple thoughts. In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From marick@m.cs.uiuc.edu: >> There are two assertions in Bill Wolfe's message: >> 1. The C community releases an unacceptable number of errors. Bill, please tell us exactly what the error rate is. I assume you must have some stats to back this up (maybe lines/errors?), or are you just making stuff up? >> 2. The C language is at least partly the *cause* of those errors. Nope, programmers that don't have a clue is mostly the cause of those errors (referring to stupid errors that Bill claims were caused by the C language). > 3. Many members of the C community exhibit an unprofessional and > irresponsible attitude regarding defect control and especially > defect prevention. > 4. Those members of the C community who ARE responsible professionals > are apparently not taking significant actions to raise the level > of software engineering professionalism within the C community. On reason you might have this observation is because Joe Smith gets a computer and *Shazam* he's a "real programmer" (CSMAJORS for short). (note: CSMAJORS here only refers to those people who got the CS degree because it pays well, there are of course "real programmers (tm)" that have CS degrees) The current market demand for programmers exceeds the supply of "real programmers (tm)" thereby creating a demand for CSMAJORS. The reason these people exist is because of the demand for people to fill programming jobs. If employers were not willing to pay top dollar for these people as programmers they would not be programmers at all, they would go and get themselves an MBA or whatever they could use to make the most money. > The unsafe constructs within C are themselves sufficient evidence to > conclude that the C community, by choosing to use a language which has > many highly unsafe constructs and an almost total disregard for error > prevention, does not hold error prevention in sufficiently high regard; Bullshivicky! What does the level of handholding a language provides have to do with anything. Making unsupportable claims undermines your argument (again). > as opposed to holding its existing reputation > as a community which contains an extremely high percentage of those who > regard themselves as hackers, and whose products repeatedly make national "regard themselves as hackers" is a key phrase here. You are again talking about the CSMAJORS, and this has nothing to do with the "C-community". This is a problem in any language, there are more CSMAJORS programming in C simply because it is becoming the language of choice (with good reason in my opinion). In the future if you want to flame some group for all the buggy code out there, go talk to the people who hire people who can't program. -- sanders Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders "she was an innocent bystander, it's a democracy" -- Jim Morrison
emuleomo@paul.rutgers.edu (Emuleomo) (03/07/90)
In article <17000003@hpcvra.CV.HP.COM>, frankw@hpcvra.CV.HP.COM (Frank Wales) writes: > In some article (William Thomas Wolfe, 2847 ) > billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > >From ekrell@ulysses.att.com (Eduardo Krell): > >> And what makes you think the network wouldn't have crashed if the software > >> had been written in Ada (you seem to imply this)? Do you know the details > >> of the cause of the crash?. > > > The crash apparently was caused by a programmer who used a "break" > > within an if (which itself was within a switch) for the purpose of > > exiting the if; the real result was to exit the switch instead. If > > C provided a case statement rather than a switch..break system, then > > the error would most likely have been prevented. > > Well, actually, the crash was caused by software which didn't work Actually, I think the 'break' as used in the switch stmt was one of the few mistakes Dennis Ritchie made when designing the C language. By using 'break' both to end a 'case', and to exit a loop, he overloaded the meaning of 'break' and thus made it impossible to jump out of a switch that is embedded within a loop without using a flag or a GOTO! Was he trying to conserve keywords? In hindsight, I think 'endcase' would have been a better choice. The other less serious flaw in C is the do...while contruct. I kind of prefer PASCAL's repeat....until construct myself. Anyway, 1.5 flaws in a language is still pretty good. I have used several languages ( >15) and in expressive power, it is difficult to beat C. Thats why its fast becoming the lingua franca of programming. --Emuleomo O.O. (emuleomo@yes.rutgers.edu) -- ** The ONLY thing we learn from history is that we don't learn from history!
cbuckley@vax1.tcd.ie (03/09/90)
In article <Mar.7.10.43.42.1990.17402@paul.rutgers.edu>, emuleomo@paul.rutgers.edu (Emuleomo) writes: > Actually, I think the 'break' as used in the switch stmt was one of the few > mistakes Dennis Ritchie made when designing the C language. By using > 'break' both to end a 'case', and to exit a loop, he overloaded the meaning of > 'break' and thus made it impossible to jump out of a switch that is embedded > within a loop without using a flag or a GOTO! I always thought "break" jumps out of the innermost construct - I presume you mean that it is impossible to jump out of the loop as a result of one of the cases in the switch() (which is imbdedded in the loop). At college, we're taught that this is bad programming practice anyway! (Yes, yes, I *know* that there are times when... etc... etc...) > Was he trying to conserve keywords? In hindsight, I think 'endcase' would have > been a better choice. However, I do kind of agree with this. It would make programs that bit easier to read - especially as a "switch" cannot really be considered a loop, so it is a bit peculiar to use a statement which implies "breaking" out of it. > The other less serious flaw in C is the do...while contruct. > I kind of prefer PASCAL's repeat....until construct myself. How can this be a flaw? The two constructs are identical except for the fact that the condition is reversed in do { } while(); If you *really* want a repeat{}until();, and you're not worried about using #define to redefine language features (and no, I do *not* want to get back into the "re: #define OR ||" argument over this), you can do : #define repeat do #define until(x) while(!(x)) *********NOTE - I would NEVER do this!!!!!!!*************** *********PLEASE do NOT send angry followups!*************** *********I KNOW it is unsound programming practice********* *********I KNOW it defeats the compiler's error-trapping*** but this is really unnecessary, as do...while is just as flexible as repeat...until - after all, every condition has a reverse. exit(0); Colm +-----------------------------------------------------------------+ | Colm Buckley. (Computer Science, Trinity College, Dublin) | | | | EMAIL : cbuckley@vax1.tcd.ie | | Phone : Dublin 770101 | +---+---------------------------------------------------------+---+ | Beware of a programmer with a screwdriver... | +---------------------------------------------------------+
marsden@ecs.umass.edu (03/13/90)
In article <39412@ism780c.isc.com>, stevee@ism780c.isc.com (Steve Ellingson) writes: > C is a language for consenting adults, > Pascal is a language for naughty children, and > Ada is a language for criminals! > As you all know: Languages don't kill algorithms, Programmers do. & If C were outlawed, only "real programmers" would have C. (hmm....) ---------------------------------------------------------------------------- internet : marsden@ecs.umass.edu Ben Marsden BITNet : marsden@umaecs Engineering Computer Services Univ. of Massachusetts phone : (413) 545-4655 Amherst, MA 01003 I think, and speak, for (a *very* small subset of) all humanity. Disclaimer: the State is not responsible...
kevin@ttidca.TTI.COM (Kevin Carothers) (03/21/90)
In article <39412@ism780c.isc.com>, stevee@ism780c.isc.com (Steve Ellingson) writes: > C is a language for consenting adults, My favorite. > Pascal is a language for naughty children, and My wife's favorite > Ada is a language for criminals! My previous employers favorite. I'm sorry. I have to ask... Since Each of these above as occupied a station in my past, for whom, pray tell, are Fortran and Cobol for? -- Kevin Carothers {philabs,csun,psivax}!ttidca!kevin
archer@elysium.sgi.com (Archer Sully) (03/22/90)
In article <11183@ttidca.TTI.COM> kevin@ttidca.TTI.COM (Kevin Carothers) writes: >In article <39412@ism780c.isc.com>, stevee@ism780c.isc.com (Steve Ellingson) writes: >> C is a language for consenting adults, > My favorite. >> Pascal is a language for naughty children, and > My wife's favorite >> Ada is a language for criminals! > My previous employers favorite. > I'm sorry. I have to ask... > Since Each of these above as occupied a station in my past, for whom, > pray tell, are Fortran and Cobol for? Managers, and other Neanderthals. Archer Sully | I'm 27 years old. That's 54 in Nerd Years (archer@esd.sgi.com) | -- Keith Rienzi
john@newave.UUCP (John A. Weeks III) (03/22/90)
In article <11183@ttidca.TTI.COM> kevin@ttidcb.tti.com (Kevin Carothers) writes: > My favorite. > My wife's favorite > My previous employers favorite. > I'm sorry. I have to ask... > Since Each of these above as occupied a station in my past, for whom, > pray tell, are Fortran and Cobol for? Fortran--for those who like to do things fast Cobol--for those who like to make money -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!bungia!wd0gol!newave!john ===============================================================================