Re: Ada language revision

[rivers@seismo.CSS.GOV (Wilmer Rivers)]

[Do not eat this line under penalty of law.]

   This is a somewhat edited version of a message I sent by E-MAIL
to SALLEN%LOCK.SPAN@STAR.STANFORD.EDU (Stanley Roger Allen) in response
to message <8811141420.AA01652@ajpo.sei.cmu.edu>.  I shall not re-post
any excerpts from his original article, but as I interpreted it he
wanted to make 2 major complaints : (1) many or most changes that are
being suggested to Ada are not adequately thought out before they are
proposed, and (2) any changes that would deviate from the original
intent of Ada's goals should be eschewed.  Although the first point
may well be correct, I should like to take mild exception to the
second one, and I am posting these remarks publicly in order to en-
courage further discussion of this issue via this newsgroup.

   The article seems to suggest that any changes to Ada should be re-
stricted to refining the grand design that was set into motion long
ago, rather than accommodating any changes that would involve a new
direction for the language.  You can certainly build a strong case for
that.  ("Here's what Ada is supposed to do, and if you want to do some-
thing else, then come up with a different language, just don't call it
Ada.")  However, proponents of more drastic changes also have a point.
Suggesting that all changes should be confined to moving from Steelman
to TitaniumMan (or ReinforcedConcreteMan, or whatever) may be too rigid.
(No pun intended, but actually the concept of rigidity is appropriate
here.)  This concept of minimal evolution reminds me of the member of
the board of directors of the Metro system here in D.C. who recently
dismissed commuters' pleas for more farecard machines in certain subway
stations by noting that introducing more machines would "interfere with
the aesthetic purity of the design" of the stations.  He's right, but
(1) commuting patterns change; (2) the farecard machines have turned out
to be less reliable than they were in the original "aesthetically pure"
design; and (3) assuming you don't want the subway stations to serve as
museums or cathedrals, what counts is not so much their architectural
splendor as how easy they make it to catch a train.  So it is with pro-
gramming languages.  (1) Programming has changed in recent years [and of
course Ada is partly responsible for that]; (2) some features of Ada
haven't *really* worked so well as the designers had intended; and (3)
whether or not the LRM is the best thought-out set of rules and specifi-
cations since the U.S. constitution is less important than whether pro-
grammers can use Ada to get their job done.  Apparently, some of them
think they can't, so they want some changes that aren't consistent with
what Steelman (and maybe even Strawman) thought Ada was supposed to do.
Is that so terrible?  The dogmatic attitude of "If it's inconsistent
with all the great effort that we've put into Ada, then it's heresy and
we musn't do it" may not be the best one for revising the language.
Sometimes it's necessary (or at least desirable) to make fundamental
changes ab initio, even if they are in conflict with what you originally
had in mind.  For example, if someone wants a language that does some of
the things that were cited in the original posting as contrary to the
goals of Ada, then is it so unthinkable for him to suggest that the new
language he needs should nevertheless still be Ada?  Saying "Nope, that
definitely isn't what Ada is all about," really just begs the issue.  An
appropriate response would be, "Maybe Ada wasn't about that originally,
but why shouldn't it be about that now?"  You shouldn't automatically
legislate against progress by saying that the goal of the language is
cast in stone (or straw, wood, tin, iron, steel, titanium, reinforced
concrete, ...).

   Well, that's my own mild flame.  In summary, I am arguing that langu-
age design purists shouldn't be allowed to use the obvious necessity for
considering very carefully any proposed changes to the LRM as justifi-
cation for outlawing a priori any changes in the *intent* of the langu-
age itself.  As I said above, a strong case can in fact be made for that
attitude, but personally I don't think making the language's goals sac-
rosanct is in the best interest of the programming community.

			    Wilmer Rivers (rivers@beno.CSS.GOV)
			    Teledyne Geotech


[I suppose I should add the standard disclaimer stating that my own
views and those of my employers may differ, but actually I doubt that
the company cares very much about this issue one way or the other, and
they would probably perfer that I didn't spend any time caring about
it either.]