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!attcan!uunet!seismo!rivers From: rivers@seismo.CSS.GOV (Wilmer Rivers) Newsgroups: comp.lang.ada Subject: Re: Ada language revision Summary: is Ada past the point at which the *goals*, as well as the syntax, can be changed ? no ... Message-ID: <44449@beno.seismo.CSS.GOV> Date: 15 Nov 88 23:28:12 GMT References: <8811141420.AA01652@ajpo.sei.cmu.edu> Organization: Center for Seismic Studies, Arlington, VA List-Id: [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.]