From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!bu.edu!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.lang.ada
Subject: Re: irregularities regarding attributes
Message-ID: <20600051@inmet>
Date: 15 Jun 90 18:27:00 GMT
References: <1958@sparko.gwu.edu>
Nf-ID: #R:sparko.gwu.edu:1958:inmet:20600051:000:1271
Nf-From: inmet.inmet.com!stt    Jun 15 14:27:00 1990
List-Id: <comp.lang.ada>


Re: Irregularities.

Keep those cards and letters coming!  We are listening,
and do hope to iron out some of the simple irregularities in Ada9X.

One thing to keep in mind, for Ada83 as well as Ada9x, is
that designing a language (or revising it) is a mind-boggling
effort, with an extraordinary number of big and little
interactions to worry about.  There always comes a time in
the design process when you have to say enough is enough.

Of course, the next day, some smart aleck comes up with a brilliant
idea.  So you try to squeeze it in under the standardization wire,
and sure enough, the following year some other smart aleck
points out that that great idea you smuggled under the wire
is inconsistent with some other corner of the language.

And ta-dah, you have an irregularity!  So Ada9X will try
to iron out Ada83's irregularities, and Ada200X will iron
out those introduced by Ada9X.  

Programming languages, being
the reflection and product of a human activity, are inevitably
far from being jewels of perfection.  The more important
goal, of course, is utility and usability, and a few irregularities
here and there don't usually destroy the usefulness (they
just annoy the heck out of us purists!).

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138