[comp.lang.c] evolution by committee

nather@ut-sally.UUCP (Ed Nather) (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.

If these are the only choices I'm offered, I guess
I would pick number 2 because I've seen it work sometimes, even though
failure is probably more likely.  C was designed by a single individual (dmr)
based on his knowledge of many other languages and ideas, on his own
experience as a programmer, and on his needs of the moment.  Is this the
ideal way to design anything?  No. Won't you end up with what HE wanted and
not what YOU want?  Sure.  But it will work if he knows what he is doing
and has a talent for design, and you may well find you can conform to his
way of doing things much easier than you can design your own.

I don't really know how much Dennis Ritchie has been involved with this
"evolutionary step" but a little boiled over into this newsgroup, so I
gather it's not zero.  So let me suggest another alternative:

5) evolution by the original designer, based on suggestions by cooperating
individuals (e.g. committee).

I've been on enough committees to recognize a serious problem: there are
too many interfaces between individuals and too little time for really
intensive iteration on problems and consequences.  A single individual
can iterate 10 times while taking a shower -- but not as a member of a
committee.  He must stop the loop after 1 cycle and check with the other
members.  With all due (and genuine) respect for the ANSI committee
members as individuals, I suggest the method itself is seriously limiting.

The ideal way to proceed, in my view, would be to come up with a proposed
standard, then give it to Dennis Ritchie and ask him to take out anything
he finds offensive, replace awkwardnesses with better solutions if he can 
find them, and take what he hands you back as the next "evolutionary step."
He may well not have the time nor inclination to do it, but I would ask.

-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather@astro.AS.UTEXAS.EDU

gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/16/88)

In article <11619@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>The ideal way to proceed, in my view, would be to come up with a proposed
>standard, then give it to Dennis Ritchie and ask him to take out anything
>he finds offensive, replace awkwardnesses with better solutions if he can 
>find them, and take what he hands you back as the next "evolutionary step."

That's not too far from the way we actually proceeded,
except Dennis did not have absolute veto power, just a strong influence.
Except for type qualifiers and a couple of minor quibbles,
he has indicated his approval of the proposed standard.

>He may well not have the time nor inclination to do it, but I would ask.

In fact, in a congratulatory letter to X3J11, Dennis indicated just that.
(I know that *I* think his time is better spent on CS research than on
standards activities.)

Your point about slow iteration is well taken, but remember that it is
somewhat mitigated by having a hundred or so C experts reviewing every
proposal.  Sequential processing is traded off against parallel processing.

Finally, standards bodies wish for a standard to reflect the needs of
the user community.  Leaving a standard up to one person would not
give them much assurance of that.

faustus@ic.Berkeley.EDU (Wayne A. Christopher) (05/16/88)

It seems to me that the best reason for having a committee design anything
is so that they all will support it.  When an individual does something,
if people don't like it they won't use it.  If they're on the committee that
did it, they're much more likely to get behind it, even if they had to
make some compromises along the way.

	Wayne