From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 26 May 93 16:50:49 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: good software engineering (was: mixing integer and logical ops)
Message-ID: <EACHUS.93May26115049@spectre.mitre.org>
List-Id: <comp.lang.ada>

In article <EMERY.93May25151706@goldfinger.mitre.org> emery@goldfinger.mitre.or
g (David Emery) writes:

  > More important, is that it makes it much easier to spot "bad" code!

     I've always thought that one of the major advantages of Ada was
that it makes bad code look so bad that the author fixes it, often
before anyone else sees it.  To really appreciate this, notice how
many of the Ada 9X revision requests reduce to "I know that it is
possible to do what I want like this:...  but that is too ugly to
use."

     This is not a criticism of many of those RR's.  There are several
cases where a necessary Ada 83 feature gets tarred with the wrong
brush.  Ada 9X does fix many of them, such as operator visibility
rules, and redefined equality operators.  But the point is that I
cannot imagine someone writing a similar revision request about C.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...