what should be added to C [generic comments on process]

[mash at mips.UUCP]

In article <5565 at alice.uUCp> ark at alice.UucP (Andrew Koenig) writes:
>> I would rather see C++ and Concurrent C making their way
>> into the ANSI standard, but, if it is unfeasible, at least
>> their usefull additions to the "old C" should see the
>> world.
>No, no, NO!
>The purpose of a standards committee is to codify current
>practice, not to engage in wholesale language redesign.
>
>C++ is an evolving language.  Its present form should NOT be
>frozen into something like ANSI C.

I second Andy's comments, not just because I agree with them,
but because the note was one of the few comments in this discussion to
rise above the nitty details into a more generic observation.
It is important to find general rules and use them to solve problems,
rather than using nothing but special cases.  Andy has stated 2 rules:

1. Things should evolve for a while before they get standardized.

2. Standards committees should codify practice, not invent things.

To this, I'd like to add a few observations on past evolution of C,
then propose a few more rules to add to Andy's:

OBSERVATIONS ON THE PAST:
Here have been a horde of C variants, even just inside Bell Labs
[before I left, I had a huge file folder full of memos on them]:
a) Minor changes, which have either disappeared, or been
incorporated into C [a while ago].
b) Pre-processors to assist specific application areas.
I think some of these survived, although they usually didn't
spread too far outside the inventors' turf.
c) Major reworks.  Those that added relatively little new
functionality generally died off. C++ has done OK.

You wouldn't believe how many times the same things were (re)invented
in slightly different ways, used a while, and died out.

Now, some more proposed rules:

0A. Ecological niche: when you invent a language, make sure it has a
real niche in the world that doesn't overlap too much with existing ones:
	a) Make it an efficient way to handle a different applications
	area (i.e., like snobol, lisp, apt, smalltalk, etc)
	OR
	b) Make it an effective way to handle an existing problem domain,
	but a different (usually higher) level, i.e., assembler -> C,
	or C -> awk, or C -> shell, or COBOL -> 4GL.
	BUT NOT:
	make yet another language of the C/PASCAL/FORTRAN level of power,
	but with a slightly different syntax.
In general, it means that of the zillions of languages invented or
proposed, only a few will become widely used.
[Read Sammet's "Programming Languages: History & Fundamentals, or
Wexelblat's "History of Programming Languages", for example].

0B. Design parsimony.  Do the original design with a few (at most!) 
knowledgable people, avoiding kitchen-sinks, and striving for a small
number of constructs, and examining each proposed feature for
its true contribution.  [Yes, motherhood, but given some of the past
discussion in this newsgroup, it may be worth pondering.]

1A. When it's still new, tweak it fast and hard in response to real usage.

1B. When it gets older, think much harder about tweaking it,
especially in non-upward compatible ways, unless the tweaks are agreed
to add great functionality. Especially, avoid adding extra ways to say the
same thing.

1C. If it's successful, it will spawn variants.


2A. When it's old, it is ABSOLUTELY USELESS AND A WASTE OF TIME TO
PROPOSE MINOR CHANGES, ESPECIALLY THOSE THAT EASILY BREAK EXISTING
CODE.  THEY WILL NOT HAPPEN.  THEY SHOULDN'T HAPPEN.  [I know it's
fun to propose changes and argue about them, and it is sometimes
useful, but IT'S TOO LATE TO DO THIS FOR C.]  Go on to something else,
like C++, or what C needs to survive good optimizing compilers, or
what features would be needed to give a language to replace C at a much
higher level, or...

Thus, we have:

0A: Ecological niche: make sure it has a place to live.
0B: Design parsimony: don't feed it too much, too early.
1: Let it evolve.
	1A: When young, tweak it.
	1B: As it ages, tweak it less.
	1C: If it lives, it will have siblings.
2: When it's almost (but not quite) ancient, standardize the family.
2A: At this point, it's too late to make the parents over; start working
on the children instead, while there's still hope.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086