Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!styx!mordor!ut-sally!utah-cs!utah-gr!donn From: donn@utah-gr.UUCP (Donn Seeley) Newsgroups: net.lang.c Subject: Re: what should be added to C [generic comments on process] Message-ID: <1737@utah-gr.UUCP> Date: Tue, 3-Jun-86 23:19:38 EDT Article-I.D.: utah-gr.1737 Posted: Tue Jun 3 23:19:38 1986 Date-Received: Thu, 5-Jun-86 19:19:54 EDT References: <1333@mtx5a.UUCP> <5565@alice.uUCp> <492@mips.UUCP> Organization: University of Utah CS Dept Lines: 246 Summary: Hooray! 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.