Xref: utzoo comp.lang.c:26640 comp.software-eng:3087
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!grimlok
From: grimlok@hubcap.clemson.edu (Mike Percy)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Currency Quotes
Message-ID: <8240@hubcap.clemson.edu>
Date: 5 Mar 90 15:00:22 GMT
References: <8229@hubcap.clemson.edu>
Organization: Clemson University, Clemson, SC
Lines: 41

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
>