bill@proxftl.UUCP (T. William Wells) (05/16/88)
In article <7890@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <11593@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes: > >It makes me nervous to realize this evolutionary step was made by a > >committee. > > Whoopie do. What are the alternatives? > 1) stagnation at a functionally inadequate level > 2) evolution by one individual's fiat (who?) > 3) evolution by cooperating individuals (e.g. committee) > 4) evolution by battling individuals > Pick one. I think I would be MORE nervous with the other alternatives. Actually, I would much prefer option 2, given that the individual in question has demonstrably got his act together. As an alternative, option 3, in the sense of cooperating individuals, can be as good as option 2, also given that the individuals know what they are doing. A committee is not, repeat NOT, necessarily a group of cooperating individuals, though it can be. As evidence for this, consider what goes on in a small group of individuals whose primary goal is to get some specific job done; then compare that to any random committee comprised of individuals with different and conflicting goals. Also, consider this: historically, the very best languages (for their specific purposes) were put together by one person or a small number of cooperating individuals; the very worst were put together by committee. Now, as for Standard C, the committee seems to have arrived at a workable method of operation: they have different goals but are attempting to not stray too far from the original intent of the language designer. It is certainly the case that some of the things they are doing are really screwed up (the worst seems to be noalias, with the reserved library names a close runner up), but in general the committee has not made it difficult for me to program with C in the style to which I am accustomed. So, from my point of view, while the ANSI committee is a committee containing individuals with conflicting goals, because it is (more or less) constrained by the original intent behind the language, the result of their deliberations has a chance to be almost as good as the result we might get from a group of cooperating individuals. And given that C is intended for programmers, who do have conflicting goals, I think that the committee is doing as well as can be done.
mjy@sdti.UUCP (Michael J. Young) (05/18/88)
In article <176@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes: >Also, consider this: historically, the very best languages (for >their specific purposes) were put together by one person or a >small number of cooperating individuals; the very worst were put >together by committee. There is a big difference between designing a completely new language from scratch and standardizing an existing language. The former is best done by a small number (perhaps one) of capable language designers. The latter is best done by a committee. Language design is a creative act, and committees are not very creative. A large part of standardization is finding common ground between all the different implementations of an existing language. In that process it is important to have as many perspectives as possible; hence, a committee. Although some might argue that X3J11 has been designing a whole new language ("it ain't C"), I think they have shown remarkable restraint (with one glaring exception, which was corrected quickly), and should be proud of their work. PS: I once saw a cartoon in which a car salesman was showing a bus to a prospective buyer. The caption read, "It's a special model for committees... it comes equipped with one gas pedal, four steering wheels and ten sets of brakes." -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779 "Bill & Opus in '88" -- Consider the alternatives!
karl@haddock.ISC.COM (Karl Heuer) (05/19/88)
In article <176@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes: >It is certainly the case that some of the things they [X3J11] are doing >are really screwed up [e.g.] the reserved library names Reserved library names are current practice. ("Reserved" meaning that you might be able to get away with redefining them, but it's not portable.) You can't blame X3J11 for that one. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
bill@proxftl.UUCP (T. William Wells) (05/29/88)
In article <266@sdti.UUCP>, mjy@sdti.UUCP (Michael J. Young) writes:
) There is a big difference between designing a completely new language from
) scratch and standardizing an existing language. The former is best done by
) a small number (perhaps one) of capable language designers. The latter is
) best done by a committee. Language design is a creative act, and committees
) are not very creative. A large part of standardization is finding common
) ground between all the different implementations of an existing language.
) In that process it is important to have as many perspectives as possible;
) hence, a committee.
Agreed, as long as the committee's actions are constrained by
respect for the original work.