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
machaffi@fred.cs.washington.edu (Scott MacHaffie) (03/05/90)
In article <8224@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > 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!!! So what's your point? Do you understand the difference between hardware and software? Do you even realize that there is a difference? Hardware is the physical parts of a computer such as the disk drives, monitors, terminals, modems, etc. Software is the programs that run on a computer. A computer program (software) can NOT provide CURRENT currency exchange rates without hardware which is designed to collect the currency rates from somewhere. ADA SOFTWARE can not deliver market reports without reading data from the market using a modem or a similiar HARDWARE device. If you're going to be stupid, please take it to an appropriate news group, such as alt.stupid.users.who.dont.have.a.clue.and.never.will. Scott MacHaffie
machaffi@fred.cs.washington.edu (Scott MacHaffie) (03/05/90)
In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > 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 You will be happy to know that in the version of Unix we are running here, the man page for "units" has nothing resembling a BUGS section. Therefore, the "units" program at this site is perfect. It is an example of high-quality software engineering because the programmers didn't include any of those stupid "bugs" sections in the man page. Do you feel stupid yet? You should.
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 .........................................................................
schmidt@zola.ics.uci.edu (Doug Schmidt) (03/05/90)
In article <8229@hubcap.clemson.edu>, billwolf%hazel (William Thomas Wolfe, 2847 ) writes: > b) irresponsible, since it indicates a flippant > approach to the reliability of the output. Lord knows we don't want flippant manual pages. What we need are more software engineering cacademoids[1]. That'll solve the software crisis right quick... 1/2 ;-) Doug ---------------------------------------- [1] cacademoid n. [fr. L caca (feces) + academe + -oid, fr. Gk eidos (form or shape)]: The lowest creature in higher education; typically, a sexually repressed, humorless, and self-impressed professor or administrator afraid of the real world, incapable of teaching and producing useful research, and hostile to new ideas; found in every kind of academic institution, cacademoids love to serve on committees, despise students, and venerate their inferior superiors. "Professor Freddy Cavity claims there are no dialect terms for genitals in American English. What a cacademoid!" -- Reinhold Aman, in "What's the Word For ...?", Harper's, Feb. 1990 ---------------------------------------- -- facilis descensus avernus ---------------------------------------- schmidt@ics.uci.edu (ARPA) office: (714) 856-4043
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
henry@utzoo.uucp (Henry Spencer) (03/06/90)
In article <10950@june.cs.washington.edu> machaffi@fred.cs.washington.edu.cs.washington.edu (Scott MacHaffie) writes: >If you're going to be stupid, please take it to an appropriate news group, >such as alt.stupid.users.who.dont.have.a.clue.and.never.will. If everybody just puts Bill Wolfe in their kill files, comp.lang.c will be a better (and less noisy) place. -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
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
CMH117@psuvm.psu.edu (Charles Hannum) (03/06/90)
In article <1990Mar5.182414.787@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) says: > >In article <10950@june.cs.washington.edu> >machaffi@fred.cs.washington.edu.cs.washington.edu (Scott MacHaffie) writes: >>If you're going to be stupid, please take it to an appropriate news group, >>such as alt.stupid.users.who.dont.have.a.clue.and.never.will. > >If everybody just puts Bill Wolfe in their kill files, comp.lang.c will >be a better (and less noisy) place. VM Netnews doesn't support Kill files. <HEAVY SIGH> I just ignore the ignorant. Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
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
hascall@cs.iastate.edu (John Hascall) (03/07/90)
In article <490595bc.1a5bf@moth.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: }In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: }> [blah, blah, blah...] } }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"? }(Let's see...how many synonyms for "bore" can we find...) Uh, how about "boor" or perhaps even "boar"? John Hascall / hascall@atanasoff.cs.iastate.edu C is a Ferrari, Ada a Volvo, drive what you can handle.
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
hstroma@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 >
jharkins@sagpd1.UUCP (Jim Harkins) (03/08/90)
In article <756@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: >In article <490595bc.1a5bf@moth.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: >}In article <8229@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >}(Let's see...how many synonyms for "bore" can we find...) > > Uh, how about "boor" or perhaps even "boar"? You forgot the obvious, "wolfe". Has anybody noticed how testy the ada people get when someone posts anything the least bit disparaging about ada in comp.lang.ada? So why do we let this dweeb cause us so much consternation? -- jim jharkins@sagpd1 "My hope is that we can use tariffs to force Japan to open their markets to imported goods. My fear is I'll be forced to buy lousy American made stuff."
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
brad@looking.on.ca (Brad Templeton) (03/12/90)
Actually, it would not be hard to write a simple sed script to map the
daily postings of the currency quotes to clari.biz.finance to 'units' format
and put them on the end of the unittab each day.
A simple news sys line entry can pipe all articles in that group. Here is
a free sample of Thursday's quotes for those who want to update their
unittab file right now.
From: clarinews@clarinet.com
Newsgroups: clari.biz.finance
Subject: Foreign Exchange Rates 3-8
Keywords: foreign exchange, money
Date: 8 Mar 90 22:38:02 GMT
Lines: 83
ACategory: financial
Slugword: forex
Priority: regular
Format: regular, close
_F_O_R_E_I_G_N _E_X_C_H_A_N_G_E
NEW YORK (UPI) -- Foreign Exchange interbank buyer rates and
foreign currency equivalents, provided by American Security Bank, Washington,
D.C. Retail transactions provide fewer units of foreign currency per
dollar.
U.S.$ Currency
Equivalent Per U.S. $
Thu Wed Thu Wed
Argntn austrl .000212 .000190 4720.00 5270.00
Australia dlr .7609 .7603 1.3142 1.3153
Austria schill .0836 .0834 11.96 11.99
Belgium frnc-c .0283 .0282 35.32 35.42
Belgium frnc-f .0283 .0283 35.36 35.35
Brazil cruzado 0.0294 0.0303 34.0000 33.0000
Britain pound 1.6390 1.6450 0.6101 0.6079
Britain 1-mo 1.6494 1.6358 0.6063 0.6113
Britain 3-mo 1.6123 1.6184 0.6202 0.6179
Britain 6-mo 1.5865 1.5925 0.6303 0.6279
Canada dollar .8472 .8455 1.1803 1.1828
Canada 1-mo .8439 .8420 1.1850 1.1876
Canada 3-mo .8462 .8357 1.1817 1.1966
Canada 6-mo .8294 .8272 1.2057 1.2089
Chile peso-f .003509 .003511 285.01 284.79
China yuan .2378 .2378 4.2050 4.2050
Colombia pes .002218 .002221 450.85 450.28
Denmark krne .1534 .1528 6.5195 6.5435
Ecudr sucr-z .001407 .001407 710.82 710.82
Egypt pound .3841 .3855 2.6037 2.5937
Finlnd mrkka .2498 .2496 4.0030 4.0060
France franc .1740 .1742 5.7455 5.7405
France 1-mo .1738 .1739 5.7547 5.7499
France 3-mo .1731 .1732 5.7772 5.7728
France 6-mo .1721 .1722 5.8105 5.8058
Greece drach .006239 .006235 160.29 160.39
Hollnd guildr .5227 .5226 1.9130 1.9135
HongKong dlr .1280 .1280 7.8122 7.8100
India rupee .0589 .0589 16.97 16.97
Indo'sa rupia .000554 .000554 1805.00 1805.00
Iran rial .0142 .0142 70.30 70.30
Iraq dinar 3.2446 3.2446 0.3082 0.3082
Ireland punt 1.5680 1.5662 0.6378 0.6385
Israel shekel .5051 .5051 1.9800 1.9800
Italy lira .000797 .000798 1254.75 1253.00
Japan yen .006621 .006656 151.03 150.25
Japan 1-mo .006627 .006661 150.90 150.12
Japan 3-mo .006638 .006672 150.64 149.88
Japan 6-mo .006652 .006685 150.32 149.58
Jordan dinar 1.5076 1.5076 0.6633 0.6633
Kuwait dinar 3.4329 3.4329 0.2913 0.2913
Lebanon pnd .001837 .001837 544.35 544.35
Mexico pes-z .000365 .000365 2742.00 2742.00
N.Zealand dlr .5885 .5875 1.6992 1.7021
Norway krne .1524 .1520 6.5625 6.5775
Pakistn rupee .0472 .0472 21.18 21.18
Peru inti .000074 .000073 13590.0 13790.0
P'pnes peso-z .0453 .0453 22.06 22.06
Portugl escd .006699 .006689 149.28 149.49
Saudi riyal .2668 .2668 3.7480 3.7480
Singapore dlr .5342 .5333 1.8720 1.8752
S.Africa rand .3882 .3886 2.5760 2.5735
S.Korea won .001451 .001454 688.99 687.70
Spain peseta .009165 .009122 109.11 109.63
Sweden krona .1624 .1618 6.1575 6.1790
Switzrl franc .6633 .6669 1.5075 1.4995
Switzrl 1-mo .6631 .6667 1.5081 1.5000
Swirzrl 3-mo .6626 .6662 1.5093 1.5011
Switzrl 6-mo .6616 .6664 1.5115 1.5005
Taiwan dollar .0385 .0385 25.98 25.96
Turkey lira .000415 .000416 2412.00 2406.00
UAE dirham .2725 .2725 3.6700 3.6700
Urug'y peso-z .001181 .001181 847.00 847.00
Venez bolivr-z .0238 .0238 42.01 42.01
W.Ger Mark .5882 .5884 1.7000 1.6995
W.Ger 1-mo .5884 .5886 1.6994 1.6990
W.Ger 3-mo .5883 .5885 1.6997 1.6991
W.Ger 6-mo .5875 .5876 1.7020 1.7017
Yugosl dinar 0.0857 0.0855 11.67 11.69
------
c-Commercial; f-Financial; z-Floating; x-N.Y. Money Market.
Interbank Buyers Rates
Source: American Security Bank, Washington, D.C.
--
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473thornley@cs.umn.edu (David H. Thornley) (03/13/90)
In article <1760@awdprime.UUCP> sanders@sanders.austin.ibm.com (Tony Sanders) writes: >... 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 :-) Actually, COBOL is a great language to be flippant in. It's just that all that typing *all* *those* *words* makes most people to numb to be flippant. COBOL forces many things to be named that really don't need names, so you are free to name your work files after old girl friends or favorite flavors of ice cream. Also, the English-like sequence makes it easy to write things like GO TO HELL and ADD GIN VERMOUTH GIVING MARTINI as part of a valid program. You can also have identifiers up to 31 characters long (unusual for a 50s language!) with hyphens for spaces, so you can get all sorts of strange names. (Not that I recommend all this in practice, you understand, but flippancy has kept me sane through long system designs.) We seem to be getting away from C, so I'm going to try to direct followups to alt.cobol. DHT