billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/04/90)
> From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >> your original complaint about >> units(1), which must have embarassed you horribly when you found out >> about floating (gasp!) currency exchange rates. > > [I replied:] Right. My self-managed IRA had a total return of > 44.43% last year; how embarassing. Maybe I should stop watching > the Nightly Business Report so often, huh? Oh, by the way, Bob, you'll be pleased to know that Reuters (which supplies the Nightly Business Report with its market data, including currency quotes) is delivering that market data using Ada software... the introduction of Ada technology into Reuters was described at the ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!! Bill Wolfe, wtwolfe@hubcap.clemson.edu
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (03/04/90)
In article <8224@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > > From goudreau@larrybud.rtp.dg.com (Bob Goudreau): > >> your original complaint about > >> units(1), which must have embarassed you horribly when you found out > >> about floating (gasp!) currency exchange rates. > > > > [I replied:] Right. My self-managed IRA had a total return of > > 44.43% last year; how embarassing. Maybe I should stop watching > > the Nightly Business Report so often, huh? > > Oh, by the way, Bob, you'll be pleased to know that Reuters (which > supplies the Nightly Business Report with its market data, including > currency quotes) is delivering that market data using Ada software... > the introduction of Ada technology into Reuters was described at the > ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!! Say what? I was talking about your original criticism of units(1) for the way its manpage admitted that the program had no way of automatically updating its exchange-rate information in real-time. You came to the embarassingly stupid conclusion that this limitation was somehow a fault of the C programming language. But go ahead and defend that conclusion if you must.... ------------------------------------------------------------------------ Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/05/90)
From goudreau@larrybud.rtp.dg.com (Bob Goudreau): > I was talking about your original criticism of units(1) for the way > its manpage admitted that the program had no way of automatically > updating its exchange-rate information in real-time. You came to > the embarassingly stupid conclusion that this limitation was somehow > a fault of the C programming language. But go ahead and defend that > conclusion if you must.... No, it was an example of the C community's cavalier attitude toward software reliability. The comment "Don't base your financial plans on the output", or words to that effect, were a) inappropriate, since the static nature of the rates is part of the specification and should not be listed in the defects section, and b) irresponsible, since it indicates a flippant approach to the reliability of the output. Bill Wolfe, wtwolfe@hubcap.clemson.edu
raymond@rosarita.berkeley.edu (Raymond Chen) (03/05/90)
In article <8229@hubcap.clemson.edu> billwolf@hazel.cs.clemson.edu writes: > a) inappropriate, since the static nature of the rates is part > of the specification and should not be listed in the defects > section, Okay, part of the problem is not realizing that the BUGS section of a man page is misnamed. The BUGS section is also somewhat misnamed. Defects reported here aren't so much bugs as shortcomings---simple bugs should be fixed before the command in installed. -Kernighan and Pike "The UNIX Programming Environment" p. 311 It really should be called "POTENTIALLY PROBLEM-CAUSING BEHAVIOR". So defects in the specification or any behavior which someone might possibly think is a bug (even if it isn't) go into the BUGS section. For example, the sentence The precedence rules are somewhat nonintuitive. belongs in the BUGS section even though it isn't a bug.
marks@ssdevo.enet.dec.com (03/05/90)
In article <8224@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes... >> From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >>> your original complaint about >>> units(1), which must have embarassed you horribly when you found out >>> about floating (gasp!) currency exchange rates. >> >> [I replied:] Right. My self-managed IRA had a total return of >> 44.43% last year; how embarassing. Maybe I should stop watching >> the Nightly Business Report so often, huh? > > Oh, by the way, Bob, you'll be pleased to know that Reuters (which > supplies the Nightly Business Report with its market data, including > currency quotes) is delivering that market data using Ada software... > the introduction of Ada technology into Reuters was described at the > ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!! Oh for crying out loud. Can we lay all this spooge to rest once and for all and get on with some *INTERESTING* SOFTWARE ENGINEERING discussions? All this childish "You jabbed me, so I'll jab you" stuff is getting old. How about some clever ideas on how to reduce the bug rate in C code? (I mentioned C specifically ONLY because I use it and have an interest in quality improvement ideas directly related to it. NOT as an indication of the superiority/inferiority of C to other languages.) I'm thinking of things along the lines of a suggestion posted recently which utilized the preprocessor. We already know about reviews, SA/SD, etc. Randy Marks (UUCP) {decvax,ucbvax,allegra}!decwrl!ssdevo.enet!marks (INTERNET) marks@ssdevo.enet.dec.com (domain-based INTERNET) marks%ssdevo.enet@decwrl.dec.com ......................................................................... "Proper technique will get you through times of no strength better than strength will get you through times of bad technique." -- Fabulous Furry Freak Brothers .........................................................................
mfriedma@oracle.com (Michael Friedman) (03/05/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >> I was talking about your original criticism of units(1) for the way >> its manpage admitted that the program had no way of automatically >> updating its exchange-rate information in real-time. You came to >> the embarassingly stupid conclusion that this limitation was somehow >> a fault of the C programming language. But go ahead and defend that >> conclusion if you must.... > No, it was an example of the C community's cavalier attitude > toward software reliability. The comment "Don't base your > financial plans on the output", or words to that effect, were > a) inappropriate, since the static nature of the rates is part > of the specification and should not be listed in the defects > section, and b) irresponsible, since it indicates a flippant > approach to the reliability of the output. I disagree. On point A you are technically correct - the possibly unreliable nature of the rates is part of the spec. On the other hand, from the point of view of producing good results, that note is in exactly the right place. It isn't as important with something like Units that has a 2 page man entry, but say we have something like csh. I'm not going to read through a hundred pages looking for caveats and warnings. I want them in one simple clear easy to use location - the Bugs section. One of the most important things about documentation is to make it useful to the reader. That's a lot more important than placing everything exactly where it belongs according to some static criteria. On point B I again disagree. Irresponsible is when someone does something careless or possibly damaging. For example, it would be irresponsible to use Units in a financial application without reading the Bugs section. Flippant comments in documentation are more evidence that people aren't overly worreid about frightening away customers, probably because most customers don't read UNIX man pages. A flippant approach to reliability is bad. Why are jokes about reliability bad? -- The passing of Marxism-Leninism first from China and then from the Soviet Union will mean its death as a living ideology ... . For while there may be some isolated true believers left in places like Managua, Pyongyang, or Cambridge, MA ... - Francis Fukuyama
fischer@iesd.auc.dk (Lars P. Fischer) (03/05/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > No, it was an example of the C community's cavalier attitude > toward software reliability. The comment "Don't base your > financial plans on the output", or words to that effect, were > a) inappropriate, since the static nature of the rates is part > of the specification and should not be listed in the defects > section, and b) irresponsible, since it indicates a flippant > approach to the reliability of the output. a) Yes, it's part of the specs, but it can't hurt to keep the user informed, can it? The user might not realize that using a static database has this effect. b) Nonsense. What would *you* have done? You might not like an occasional humorous remark, but calling it irresponsible is plain silly. /Lars -- Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.
darcy@druid.uucp (D'Arcy J.M. Cain) (03/05/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >> I was talking about your original criticism of units(1) for the way >> its manpage admitted that the program had no way of automatically >> updating its exchange-rate information in real-time. You came to >> the embarassingly stupid conclusion that this limitation was somehow >> a fault of the C programming language. But go ahead and defend that >> conclusion if you must.... > > No, it was an example of the C community's cavalier attitude > toward software reliability. The comment "Don't base your > financial plans on the output", or words to that effect, were > a) inappropriate, since the static nature of the rates is part > of the specification and should not be listed in the defects > section, and b) irresponsible, since it indicates a flippant > approach to the reliability of the output. > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu > Where do you work? In a monastary? Lighten up will ya. Just because someone is aware of the limitations of their program doesn't mean they have to hold a funeral over it. Besides the comment "Don't base your financial plans on the output" doesn't sound all that flippant. I would take that admonition to heart if I was making multi-currency decisions. Sheesh! Someone give the guy a black armband while the rest of us get back to the party. -- D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all D'Arcy Cain Consulting | the government we pay for. West Hill, Ontario, Canada | (416) 281-6094 |
grimlok@hubcap.clemson.edu (Mike Percy) (03/05/90)
From article <8229@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >> I was talking about your original criticism of units(1) for the way >> its manpage admitted that the program had no way of automatically >> updating its exchange-rate information in real-time. You came to >> the embarassingly stupid conclusion that this limitation was somehow >> a fault of the C programming language. But go ahead and defend that >> conclusion if you must.... > > No, it was an example of the C community's cavalier attitude > toward software reliability. The comment "Don't base your > financial plans on the output", or words to that effect, were > a) inappropriate, since the static nature of the rates is part > of the specification and should not be listed in the defects > section, and b) irresponsible, since it indicates a flippant > approach to the reliability of the output. > Re: point a) I don't recall ever having read the specification to units...has anyone else? I'd rather have some sort of statement in the documentation (on-line or otherwise) that the user would commanly have access to rather than some (possibly) non-existent specification documentation that users won't usually be provided with. Re: point b) irresponsible and flippant are relative terms which are a matter of opinion. If its your opinion that the aforementioned comments are flippant, well that's your opinion. I tend to get bored wading through bland documentation written by software engineers and technical writers. The interjection of some light-heartedness is hardly a crime, particularly when the software is not related to the safety of anyone. C is not the problem here. Any language can produce horrible constructions and programs. Any programmer can produce comments and documentation which does not meet Bill Wolfe's stringent requirements, daresay that no one but Bill can meet Bill's requirements, since apparently what Bill wants is perfection in all its boring splendor. > > Bill Wolfe, wtwolfe@hubcap.clemson.edu >
tneff@bfmny0.UU.NET (Tom Neff) (03/05/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > No, it was an example of the C community's cavalier attitude > toward software reliability. The comment "Don't base your > financial plans on the output", or words to that effect, were > a) inappropriate, since the static nature of the rates is part > of the specification and should not be listed in the defects > section, and b) irresponsible, since it indicates a flippant > approach to the reliability of the output. This is pretty silly. Do Ada fans ever strike you-all as just a teeny bit defensive? :-) If the original poster wants a serious discussion, then some heavy duty definition of terms (starting with what's a "C community") is in order. But something tells me that's not quite what's going on here... maybe we should all just smile and say, "Very good Bill!" and move on to the next thing. -- "Nature loves a vacuum. Digital \O@/ Tom Neff doesn't." -- DEC sales letter /@O\ tneff@bfmny0.UU.NET
oz@yunexus.UUCP (Ozan Yigit) (03/06/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > No, it was an example of the C community's cavalier attitude > toward software reliability. No, it is a programmer's realistic attitute towards the limitations of an often-useful program. It has nothing to do with the so-called C Community. But wait !!! You exist on this network precisely because of other programs of the type you criticise. Or maybe... you are a badly written program yourself !!! :-) A PC program called "racter" has better conversational skills than you do. Did you ever post onto the net under the name "Ken Arndt" ??? [Sorry Ken !] oz -- There are two kinds of fool. Internet: oz@nexus.yorku.ca One says, "This is old, and therefore good" Uucp: uunet!utai!yunexus!oz And one says "This is new, and therefore Better" Bitnet: oz@[yulibra|yuyetti] John Brunner (The Shockwave Rider) Phonet: +1 416 736-5257x3976
jnixon@andrew.ATL.GE.COM (John F Nixon) (03/06/90)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > My self-managed IRA had a total return of > 44.43% last year; how embarassing. Maybe I should stop watching > the Nightly Business Report so often, huh? (I know this has nothing to do with C, or software engineering...) Gee, sounds like you are really pushing it; either you are making extremely risky decisions with your retirement money (not very smart), or you made a bad career choice when you decided to work with computers. Warren Buffet will need a successor one day... :-) :-) (ok, ok, I'll learn...) ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion
chrisl@caen.engin.umich.edu (Chris Lang) (03/06/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > No, it was an example of the C community's cavalier attitude > toward software reliability. The comment "Don't base your > financial plans on the output", or words to that effect, were > a) inappropriate, since the static nature of the rates is part > of the specification and should not be listed in the defects > section, and b) irresponsible, since it indicates a flippant > approach to the reliability of the output. Why don't we ALL chip in and buy Bill a nice thesaurus, so he can come up with synonyms for "cavalier", "flippant", "irresponsible", and "inappropriate"? Each of these words, all very subjective opinions, has permeated most of his postings so far...and seem to form the backbone of his argument. Maybe we could also pay for him to take a course in discussion which relies on facts and logical debate rather than repetitive babble, as well. (Let's see...how many synonyms for "bore" can we find...) -Chris ----- Chris Lang University of Michigan, College of Engineering home: 4622 Bursley work: National Center for Manufacturing Sciences Ann Arbor, MI 48109 900 Victors Way, Suite 226 (313) 763-1832 Ann Arbor, MI 48108 chrisl@caen.engin.umich.edu (313) 995-0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
shaw@paralogics.UUCP (Guy Shaw) (03/07/90)
In article <1990Mar4.213359.14687@agate.berkeley.edu>, raymond@rosarita.berkeley.edu (Raymond Chen) writes: > The BUGS section is also somewhat misnamed. Defects reported > here aren't so much bugs as shortcomings [...] > > It really should be called "POTENTIALLY PROBLEM-CAUSING BEHAVIOR". Some flavors of UNIX(TM) come with separate CAVEATS and BUGS sections in the commands reference manual. Interactive does this. At least they used to long ago; I don't know if they still do. I wish this were a more common practice. -- Guy Shaw Paralogics paralogics!shaw@uunet.uu.net or uunet!paralogics!shaw
shaw@paralogics.UUCP (Guy Shaw) (03/07/90)
Mr. Wolf's posting about "the C community's cavalier attitude toward software reliability" encompassed enough subject matter that it was bound to generate many threads about various aspects (sort of like sitcom spin-offs). In this article, I address only the issue of the appropriateness of lumping all manner of shortcomings into the BUGS section of a reference manual. In article <1990Mar4.235537.3757@oracle.com>, mfriedma@oracle.com (Michael Friedman) writes: > In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > No, it was an example of the C community's cavalier attitude > > toward software reliability. The comment "Don't base your > > financial plans on the output", or words to that effect, were > > a) inappropriate, since the static nature of the rates is part > > of the specification and should not be listed in the defects section > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [...] > > I disagree. > > On point A you are technically correct - the possibly unreliable > nature of the rates is part of the spec. On the other hand, from the > point of view of producing good results, that note is in exactly the > right place. [...] > entry, but say we have something like csh. I'm not going to read > through a hundred pages looking for caveats and warnings. ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^ > I want them > in one simple clear easy to use location - the Bugs section. [...] Yes, Mr. Wolf has a point and so does Mr. Friedman, but there are more possibilities than just the two extremes of a) lumping things in the BUGS section and b) distributing caveats throughout the reference manual. To be fair, Mr. Wolf did not offer (b) as the only alternative. In fact, he said nothing more specific about how he would organize a reference manual. Mr. Friedman's reaction is very understandable, though, because caveats sprinkled throughout the reference manual, where each subject naturally arises, *is* the alternative style that actually occurs in AT&T UNIX reference manuals. And, like diseases of the lymphatic system, it is nearly impossible to treat with surgery. The approach of having separate CAVEATS and BUGS sections solves the problem of where to put limitations, shortcomings, non-intuitive behavior, etc. without calling it all BUGS, and still lists them in one easy to find place. It is more precise. Nothing else is sacrificed for the the gain in precision. This is more than just armchair reference manual designing. I have used slightly non-standard (improved!) UNIXoid manuals that do it this way. It works for me. I wish it were more common practice. To the reference manual designers at AT&T: try it, you'll like it. -- Guy Shaw Paralogics paralogics!shaw@uunet.uu.net or uunet!paralogics!shaw
peter@ficc.uu.net (Peter da Silva) (03/08/90)
I've also seen the BUGS section labelled WARNINGS, thus avoiding complaints
by the overly literal-minded.
This is not a C issue. Please direct followups elsewhere.
Side comment, how about a comp.unix.misc?
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \ 'U`
\_.--._/
vhstroma@hubcap.clemson.edu (hepburn m stroman) (03/08/90)
From article <8224@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): >> From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >>> your original complaint about >>> units(1), which must have embarassed you horribly when you found out >>> about floating (gasp!) currency exchange rates. >> >> [I replied:] Right. My self-managed IRA had a total return of >> 44.43% last year; how embarassing. Maybe I should stop watching >> the Nightly Business Report so often, huh? > > Oh, by the way, Bob, you'll be pleased to know that Reuters (which > supplies the Nightly Business Report with its market data, including > currency quotes) is delivering that market data using Ada software... > the introduction of Ada technology into Reuters was described at the > ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!! > > Is that all that relevant? Software is written in a variety of for a variety of reasons. Reuters chose Ada. So what? It could have been a choice based on convenience, or government requirement (which seems to be the big reason for using Ada). If your comment is intended to show Ada is supeior because a _real_ product uses it, then perhaps I should list the hundreds (thousands?) of commercial products that use C (or cobol or fortran). Many applications were and are being developed in them. Since more programs are written in C, I suppose your logic must lead to the concluion C is superior (after all, more real software is written in it) Oh, and about your IRA. I'm impressed, but it is irrelevant to your point in your original post (namely, that units() was an example of bad C coding practice.) As a software engineer, you really should have researched units() and discovered the use of a data file before your initial posting. Also, to add validity to your original point, it would have been nice to see some proof that the few programs described were C-language products. > Bill Wolfe, wtwolfe@hubcap.clemson.edu >
sanders@sanders.austin.ibm.com (Tony Sanders) (03/10/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > section, and b) irresponsible, since it indicates a flippant > approach to the reliability of the output. Bill (mind if I call you Bill?) is complaining that we are "irresponsible" because we have a "flippant approach to the reliability of the output." I guess he would like all software people to wear ties and not have sense of humor. Maybe we should all get MBA's while we are at it. Hey, lets all take up COBAL, there is no way in h*ll that you can have a flippant approach to ANYTHING in COBAL :-) -- 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