rcd@nbires.UUCP (Dick Dunn) (06/10/86)
from Andrew Koenig: >No, no, NO! >The purpose of a standards committee is to codify current >practice, not to engage in wholesale language redesign. and from John Mashey, agreeing: >1. Things should evolve for a while before they get standardized. > >2. Standards committees should codify practice, not invent things. As much as I respect the opinions of these people, I think I should point out that this is not at all the role of standardization as used in the creation of Ada(tm), which we all know is the Way of the Future. The evolution sequence for Ada was/is: 1. Specify requirements on minor details of the language. 2. Design the language, preferably by committee. 3. Standardize the language. 4. Implement the language. 5. Validate the implementations. 6. Use the language to write real code. Note that standardization must happen EARLY in the evolution of a language so that design ideas can be frozen as they are developed. This keeps the language from being tainted by the results of implementing or using it. It also provides a defense against criticism: "We can't change it now; it's a standard." Oh yeah, before people get too upset, I'd better say :-) Actually, the creation of Ada involved a variety of ideas, many of them just as novel as standardizing a language that had never been implemented or used. For example, there were four competing design efforts--four committees, as it were, from whose efforts a meta-committee selected the winner. If you like "committee design" you'll love what TWO layers of it can do. This article is a :-), of course, but if you think I'm joking about Ada standardization, find ACM's strong position statement against early standardization of Ada and note how DoD thumbed its nose at ACM's position. You might also read Tony Hoare's comments in his Turing Award Lecture. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Lately it occurs to me what a long, strange trip it's been.