Xref: utzoo comp.lang.misc:7114 comp.arch:21692 Newsgroups: comp.lang.misc,comp.arch Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!rochester!kodak!ispd-newsserver!ism.isc.com!ico!rcd From: rcd@ico.isc.com (Dick Dunn) Subject: Re: Algol68 (and standards diatribe) Message-ID: <1991Mar28.011025.16337@ico.isc.com> Summary: standards process discourages readable standards Organization: Interactive Systems Corporation, Boulder, CO References: <3787@bruce.cs.monash.OZ.AU> <9168@castle.ed.ac.uk> <5591@mcrware.UUCP> Date: Thu, 28 Mar 1991 01:10:25 GMT jejones@mcrware.UUCP (James Jones) writes: > rcd@ico.isc.com (me) writes: > > [stuff about Algol 68 having problems because no readable definition] > Well...I wish I remembered who it was that pointed out in SIGPLAN Notices > some time back that the easy-to-read standards (Pascal given as case in > point, but nowadays the same can be said of C) were also full of holes, > and that attempts to make them rigorous also made them much longer and > less legible... While it is true that there are holes in both J&W and K&R, the holes are nowhere near as numerous or as big as people like to make them out to be. One reason you need the big, clunky standards is to avoid the tort-lawyer syndrome--where people intentionally go looking for holes in the language definition, instead of reading it intelligently. (I suppose one could also call this the Weirdnix syndrome.:-) I've spent a fair amount of time down inside Pascal compilers, and a little bit of time inside C compilers, plus a lot of time using both, and I've found very few questions that couldn't be answered by a careful, honest reading of J&W or K&R, respectively. When you place the reader in an adversarial role to the author, you make it very hard to produce anything readable! Writing is communication; the typical standard is written with the assumption that the reader will attempt to misunderstand (i.e., reject communication) whenever possible. Also, although the standards process supposedly attempts to produce rigorous definitions, it does so by an incredibly expensive, slow, stupid, and roundabout method. You don't get good designs out of committees; there's certainly no reason to expect good standards out of them! Stan- dards committees usually get a few good people (perhaps 20% of a typical committee, ultimately producing 80% of the work). Then they get filled up with people who have axes to grind, peter-principled mid-level-managers who get to go to meetings as a job perk 'cause they like to travel, deadwood who get sent to meetings so that the folks back home can get some work done while they're gone, and so on. In the name of "fairness", every possible conflict within the industry is represented from both sides, maximizing the number of issues which require extensive debate and mini- mizing the likelihood that the end result will be cohesive. In the end, some important issues are decided based upon which committee members are the stubbornest. I'd bet that a usable C standard could have been produced by gathering a small committee to pick apart K&R, looking for problem areas and loopholes, submitting a short problem list to K and/or R, contracting with them or the BLabs for their time to produce a revision. It would have cost 1/10 as much and produced a better result in a fraction of the time. The standards process carries an incredible lot of baggage. (Yes, I know the process I'm suggesting doesn't meet the rules of ANSI or ISO or even IEEE...and I don't care. I'm only trying to hypothesize something that could work better than the sorry mess we've got today.) So...stripped of my diatribe, the point is that YES, cleaning up a language definition is going to make it slightly less accessible--but it need not become so much less accessible as the standards process usually achieves. >...(Said person also made the same point being made in the > original posting, that a straightforward standard, even if leaky, encourages > implementors.) Right! Not only do you get more implementors; you get a lot more users! Remember, an implementor has much more incentive to dig through details and formalisms. Coming back to something related to my point about Algol 68, I'll say that you have the best chance of getting a bunch of good implementations and a real user community if you can get the implementations done and out into the world before a standard is inflicted on the language! -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 The Official Colorado State Vegetable is now the "state legislator".