mash@mips.UUCP (06/02/86)
In article <5565@alice.uUCp> ark@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
donn@utah-gr.UUCP (Donn Seeley) (06/04/86)
Mashey's second law:
2. Standards committees should codify practice, not invent things.
I'm sure happy to see that I'm not alone in espousing this position...
I hate seeing a language destroyed by 'little improvements' introduced
by a 'standards committee'. (Does 'standards committee' qualify as an
oxymoron?) The only people these 'improvements' satisfy, in general,
are standards committee members, not users, not compiler implementers.
If you're not happy with a standard language, use another language --
Cthulhu knows there are myriads of languages to choose from.
I'm finally persuaded to re-post Alan Watt's classic posting on
bureaucracy, standards and committees... I hope he doesn't mind,
wherever he is. It seemed appropriate to circulate it again, five
years after it was written.
Donn Seeley University of Utah CS Dept donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn
------------------------------------------------------------------------
From: sdchema!sdcsvax!philabs!cmcl2!floyd!harpo!decvax!ittvax!swatt
Newsgroups: net.lang.c
Title: Re: indentation
Article-I.D.: ittvax.469
Posted: Mon Oct 25 10:30:20 1982
Received: Tue Oct 26 15:28:54 1982
References: rocheste.133
The current discussion is a perennial one, and I thought the following
might be of interest. Please note the disclaimer.
- Alan S. Watt
>From swatt Sun Jun 7 13:29:28 1981
To: decvax!chico!teklabs!tekmdp!stevenm
Subject: C Beautification
Cc: swatt
From decvax!duke!chico!teklabs!tekmdp!stevenm Sat Jun 6 23:05:10 1981
C Beautification : NET.general,net.general
Does anyone out there have a C indenter/paragrapher/beautifier
which is smarter than 'cb'? I have resurrected an old one
from U. Illinois at Urbana which accepts V6 C, and I don't feel
like trying to upgrade it. I need something that will move
comments around, deal intelligently with definitions, etc.
respond to 'duke!chico!teklabs!tekmdp!stevem'
Steve:
Long time no see. How is dear old TEK anyway? I really don't
have any information on C beautifiers for you, but TTI* has a management
philosophy that might be applicable to the problem. Or you can simply
tell people who write C code what indenting practices to use and cut
off the hands of the ones who don't listen.
- Alan
-------------
* TTI is a ficticious company. It stands for "Transcendental
Telecommunications Industries" and is a multi-national conglomorate.
Any resemblance between TTI and any real company is purely coincidental.
-------------
1) Convene a committee to determine the standards. It is not
required that any members of the committee have any C
programming experience. In fact, members are chosen by the
political considerations of which groups, companies, countries,
etc. might be offended if they were left out of the decision
process.
2) Just because you have a committee doesn't mean you can actually
meet. Next get funding. This process involves filing a "PAR",
which has to list all the expected costs, all the expected
benefits, and must show how TTI will profit from this
endeavor. This has to go to World Headquarters in NY for
discussion. Now the composition of the committee really proves
its worth because if you had left anyone out who had any means
of retaliation, the PAR would either get sent back on some
technicality or die quietly in someone's office.
2) The above composition of the committee will help insure that any
standard that is produced will be late, imprecise, and quite
probably incomprehensible as well. It is expected that during
the definition of the C formatting standard many members of the
committee will raise the point "But all these problems would
just go away if we used {PASCAL|ADA|CHLL|PL/1...}". This is
all to the good as it practically guarantees there will be
sections in the final document like:
"Indentation Standards for 'COMMON' Statements"
which will help in the review process (more on that later).
3) Regardless of how long the definition of the standard takes, it
is imperative that every month the manager in charge of the project
produce a monthly report showing the projected milestone dates and
the actual milestone dates. This report is incorporated in turn
into the monthly report of the managers in charge of projects
actually using C, to show how their project delivery schedule will
slip if the formatting standard isn't delivered when promised.
4) Another important activity is the preparation of slides, foils,
charts, etc., for use at various TTI management meetings. This
activity will probably account for most of the actual
expenditures. After all, anyone can scribble some words on
paper but color artwork is EXPENSIVE. The purpose of these
various talks and presentations is to show how "the
industry-wide trend is towards common definition of programming
language source code bulk entry standards." This is also an
excellent opportunity to discuss possible uses of
state-of-the-art graphic input technology. Above all, leave
everyone with the impression that TTI is at least even with
the Bell System in this area.
5) By this time, the original committee will have hired additional
personnel, mostly secretarial. Somewhere between 8 months and
a year will have passed. The volume of work in preparing foils
for presentations will have almost certainly have outgrown
whatever computer system you started working on. Now is the
time to start pushing for your own system. The choice will
probably come down to VAX or IBM. The process of making this
decision will take another 4 months.
6) After sufficient secretarial personnel have been hired, the idea
will occur to someone to hire some programmers. By this time a
hiring freeze will be in effect, so the monthly reports will all
cite the hiring freeze as the reason publication of the standard
will be delayed. Similarly, the units awaiting the standard to
write C code will be delayed. There will be talk about abandoning
the use of C and switching to PASCAL.
7) By this time, the original request for a VAX-11/780 will have
been denied because of a budget crunch related to the hiring
freeze. There is also some suspicion that supporters of IBM
worked behind the scenes to get it killed. Productivity is
really suffering now; the production rate of foils and slides
is way down and the travel budget to go to the meetings and
present them has also been cut. Some of the members of the
committee will have declared the impossibility of getting any
work done with totally inadequate resources and have stopped
attending meetings. The production of memos should continue at
the normal rate however.
8) The hiring freeze is still in effect but it is now summer and
you can manage to hire a couple of students as summer interns.
They will probably have no experience with C, but have used
some PASCAL, and besides they'll do anything for the money.
9) The idea will certainly occur to someone that a program to format
C programs would be a nifty idea, as well as "sellable".
Debate immediately insues as to what language to write it in.
Here is where the IBM stalwarts get even for the DEC supporters
having slipped the recommendation for a VAX past them. It is
decreed that the C beautifier program will run on an IBM 4341
under VM/CMS/SPF and will be written in PL1.
10) The original project using C, a microprocessor-based field
communications system for the military, is now late and the
contractor responsible decides to give up on C and code in
assembly. This decision is quick to implement because the
military agency reponsible for overseeing the contract approved
this particular assembler for use by this particular company
for the last project. As stipulated in the contract, all
development is done on a machine donated to the company for
that purpose from military surplus stores. It is a ruggedized
NOVA and doesn't run VM/CMS/SPF or support PL1.
11) The summer student interns, after reading some C manuals
will have written the bulk of the formatting standard and a
prototype of the formatting program in about a week of
all-nighters.
12) Now some additional budget resources have become available and
production of high-quality presentation materials resumes its
former level. The standard is carefully edited to remove any
references or phrases that might offend somebody. For example,
the description of C as a "Structured Programming Language" will
have been stricken from the report because of objections of
PASCAL and ALGOL adherents who are real sticklers for the use
of the term "structured".
13) The proposed standard is now submitted for review. Now the
wisdom of including sections on the proper indenting of
COMMON statements is manifested. The reviewers will have no
more knowledge of C than did most of the committee members
at the outset of the whole affair. Giving them something to
which they can relate greatly eases the review process. You
must have been very careful, however, to cite references to
publications that have discussed this issue.
14) During the review process, someone who really does know C will
have gotten ahold of a copy of the standard and will produce
a memo showing that the standard is largely inapplicable to
the C language in its current definition (the committee used
documents for a version of the language several versions old),
and the C doesn't now have and never has had a COMMON statement,
and that the proposed standard is at variance with just about
all the C code produced by long-time C users. He will be told
that:
a) the version skew isn't important because it
describes the version of C that TTI is currently not
using anyway. This is also the reason TTI cannot start
not using a newer version because it would conflict
with the proposed formatting standard.
b) the lack of a COMMON statement cannot be mentioned
because one of the most important reviewers only
approved the standard because it adopted his view of
the proper indentation of COMMON statements. If he
finds out there isn't one he will insist that the
language be modified to include it.
c) the formatting practices of long-time C users have
been found by the committee to be "poor practice". And
besides, they couldn't be produced by the formatting
program.
15) In due course the proposed standard will be approved, with some
modifications and incorporated into the "TTI Programming
Procedures Manual". All programmers hired by TTI will be told
they must conform to the standards defined here. The manual
itself, made up of 8 volumes and totalling 3478 pages collected
over a period of 18 years, is so expensive to print that the
only copies of it are kept in designated TTI reference
libraries. It is therefore very difficult for TTI programmers
to get a copy. This is just as well because TTI in general
underpays programmers and the tenure of a programmer at TTI is
well below the industry average, so reading the entire procedures
manual would take up most of his employment span with the company.
16) The fact that no possible use of the standard will expose its
flaws has made the whole project a huge success. Everyone is
working overtime to take as much credit as possible (except the
summer interns; they are back in school trying to take as few
credits as possible). Even the ones who stopped attending the
committee meetings will be producing memos and foils showing
how their single-minded dedication to the task was what really
got it done. There will probably be promotions for everyone.
At least one more round of presentations will take place to show
what kind of disaster would have occurred if TTI hadn't moved
"significantly ahead of the rest of the industry" to define this
standard.