Appreciation for ANSI C committee (was Re: Bug in new K&R?)
T. William Wells
bill at proxftl.UUCP
Tue May 17 01:20:58 AEST 1988
In article <7890 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <11593 at ut-sally.UUCP> nather at 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.
More information about the Comp.lang.c
mailing list