Xref: utzoo comp.lang.c:26531 comp.software-eng:3036
Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!usc!jarthur!jseidman
From: jseidman@jarthur.Claremont.EDU (James Seidman)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: C Community's Cavalier Attitude On Software Reliability
Message-ID: <4795@jarthur.Claremont.EDU>
Date: 3 Mar 90 21:56:17 GMT
References: <7351@arcturus> <8212@hubcap.clemson.edu>
Followup-To: comp.lang.c
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 51

In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From evil@arcturus.UUCP (Wade Guthrie):
>   If a currency conversion program is based on the exchange rates
>   as of a given date, then this is a continuation of the specification 
>   which does not belong in the DEFECTS section.   

The manual page for units(1) clearly states that the full list of available
units is contained in /usr/lib/units.  At least on my machine, this file
gives a clear reference for the source of the monetary conversions,
including date, newspaper, and exchange.  I'll assume you've studied a
little software engineering so you'll understand this:  The *program* is not
based on any exchange rates, it merely accesses a *data file* which contains
them.  Therefore any vendor can update this data file with newer values.

>   Under no circumstances should a DEFECTS section contain flippant
>   comments such as "I tinker a lot, so things break, but then I fix
>   them, hooray", "Not bloody likely", or other comments which indicate
>   a cavalier attitude toward software reliability.  

If I remember your initial post, the "tinker a lot" comment is from BBEMACS
and the "Not bloody likely" was from some similarly esoteric program.  I
don't know who wrote these programs or where you found them, but they may
just be some local hack.  Would you please check to find out where these
programs came from and limit yourself to condemning the appropriate authors?

>   DEFECTS sections exist for the purpose of listing known areas in
>   which an implementation does not correspond to the specification,
>   along with potential workarounds (if any) and the estimated date
>   of repair.  Now compare this with your typical Unix BUGS section.

You never define a DEFECTS section.  Under what environment do you find
these?  In any case, my *typical* BUGS section is quite helpful.  If you
look at the BUGS section for jove(1), cc(1), more(1), msg(1), or any of a
host of other programs you will find no flippancy at all.

Also, if your complaints are with UNIX, might I suggest that you rant and
rave in the UNIX newsgroups?  Not all of UNIX is written in C, and by no
means is all that is written in C part of UNIX.  Having written thousands of
lines of C code under MS-DOS and VMS I can testify to this.

Lastly, if you are really concerned about this cavalier attitude, why don't
you write letters to some of the companies that do C programming?  They
might not realize how irresponsible their programmers are being.  I'm sure
that SCO, OSF, Microsoft, Borland, and all those other companies would know
exactly what to do with a letter from you explaining how they need to teach
their employees about software engineering.
-- 
-------------------------------------------------------------------------------
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.