daveb@geaclib.UUCP (David Collier-Brown) (11/06/88)
From article <141@twwells.uucp>, by bill@twwells.uucp (T. William Wells): > Here we get the same old argument, rehashed: "efficient code is > unreadable". It is not necessarily true. And in many cases, the > claim of unreadability is merely a demonstration that the reader does > not make it a practice to read that kind of code, rather than a valid > claim that the code is inherently unreadable. A good counter-example to the claim that efficient code is unreadable (and also the claim that its non-portable) exists in the TeX typesetting implementation. The author was concerned with all three, and so invented a language (formerly called DOC, now WEB) to allow the three to coexist. Regrettably, it works best for monstrous great books, not little critical bits... Donald E. Knuth, "TeX: The PRogram", Volume B of "Computers and Typesetting", Reading, Mass (Addison-Wesley), 1896. --dave (ah well, some people don't read) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | HE's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
barmar@think.COM (Barry Margolin) (11/08/88)
In article <3386@geaclib.UUCP> daveb@geaclib.UUCP (David Collier-Brown) writes: > A good counter-example to the claim that efficient code is >unreadable (and also the claim that its non-portable) exists in the >TeX typesetting implementation. First, a disclaimer: I've never found WEB programs very understandable, and the coding style it appears to promote is not very good (there's LOTS of global variables). More to the point, though, is that I think you are talking about a different kind of readability than what WEB addresses. WEB attempts to make the program layout more readable, by using fonts to highlight things like comments, and by loosening the restrictions on the order in which program elements must appear, so that the text can follow the design better. However, the kind of readability being pitted against efficiency is at a lower level. For example, if 'a>>b' is used in C as an efficient way to divide a positive number by 2**b, it will be just as confusing in WEB. WEB doesn't have any magic way to make confusing statements or algorithms less confusing. It does promote more thorough commenting, but that doesn't guarantee anything; we've been asking people to comment vigorously for years (and I admit that I'm guilty of commenting less than I should). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/10/88)
In article <3386@geaclib.UUCP> daveb@geaclib.UUCP (David Collier-Brown) writes: > A good counter-example to the claim that efficient code is >unreadable (and also the claim that its non-portable) exists in the >TeX typesetting implementation. > The author was concerned with all three, and so invented a >language (formerly called DOC, now WEB) to allow the three to >coexist. Regrettably, it works best for monstrous great books, not >little critical bits... WEB has little to do with portability; in fact Knuth relied heavily on the existence of an OTHERWISE clause in CASE statements throughout the TEX source, and that is not standard Pascal. There is also debate about whether WEB is really worthwhile; a couple of years ago in the Programming Pearls column in CACM, Knuth contributed a WEB example which Doug McIlroy really tore apart. We should probably limit the code readability discussion to code as it is prepared for a standard compiler, not a version requiring preprocessing with some additional tool.
ok@quintus.uucp (Richard A. O'Keefe) (11/11/88)
In article <8839@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >We should probably limit the code readability discussion to code >as it is prepared for a standard compiler, not a version requiring >preprocessing with some additional tool. A discussion on code readability might well move to comp.lang.misc. One would not want to ignore, for example, using SEDIT with INTERLISP. Even a WEB-like tool can be extremely simple, if the language it is meant for is straightforward. If discussion is limited to what you can do for C in "ed", I would like to suggest that a lot of the effort people put into putting huge stereotyped headers in front of _functions_ is largely wasted: the thing which needs careful explanation in a lot of programs is the data structures (and _NO_, C++ doesn't help: it simply provides more machinery to help the coder make things obscure). When you know what a data structure is for, what invariants it is supposed to satisfy, and have a couple of examples to look at (including debugging code for displaying and validating them), it's ususally pretty easy to follow the code (if the variable names are reasonable).
smryan@garth.UUCP (Steven Ryan) (11/12/88)
> There is also debate >about whether WEB is really worthwhile; a couple of years ago in the >Programming Pearls column in CACM, Knuth contributed a WEB example >which Doug McIlroy really tore apart. He attacked the algorithm, not so much the presentation. -- -- s m ryan +--------------------------------------------------------+---------------------+ | `Lisa.' He swallowed hard. `Lisa take my hand.' | Enough of this | | She looked up into his eyes and slowly took his hand. | stuffy-stuff. | +--------------------------------------------------------+---------------------+
dsb@Rational.COM (David S. Bakin) (11/12/88)
In article <1859@garth.UUCP>, smryan@garth (Steven Ryan) writes: >> There is also debate >>about whether WEB is really worthwhile; a couple of years ago in the >>Programming Pearls column in CACM, Knuth contributed a WEB example >>which Doug McIlroy really tore apart. > >He attacked the algorithm, not so much the presentation. I don't think he attacked the algorithm -- the algorithm was new and totally elegant. But in the context of the particular problem it was like going after a fly with a cannon. But Bentley (the column editor) defended it on the grounds that it was, after all, an example, the problem was simple so the solution could be published in a monthly column, but a problem that simple (solved with a Unix 1-liner) wouldn't be a good exposition of WEB. -- Dave ---------------------------------------------------------- Dave Bakin (408) 496-3600 c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197 Internet: dsb@rational.com Uucp: ...!uunet!igor!dsb
daveb@geaclib.UUCP (David Collier-Brown) (11/13/88)
From article <8839@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > In article <3386@geaclib.UUCP> daveb@geaclib.UUCP (David Collier-Brown) writes: >> A good counter-example to the claim that efficient code is >>unreadable (and also the claim that its non-portable) exists in the >>TeX typesetting implementation. [lots deleted] > We should probably limit the code readability discussion to code > as it is prepared for a standard compiler, not a version requiring > preprocessing with some additional tool. It was a counter-example, not a sugestion that everyone go out and wriet a WEB (as I once did). In fact, the idea is usefull but the first try had some problems (:-)). --dave (If you didn't like Knuth's, you'd **hate** mine) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | HE's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
mouse@mcgill-vision.UUCP (der Mouse) (11/15/88)
In article <3386@geaclib.UUCP>, daveb@geaclib.UUCP (David Collier-Brown) writes: > A good counter-example to the claim that efficient code is unreadable > (and also the claim that its non-portable) exists in the TeX > typesetting implementation. > The author was concerned with all three, and so invented a language > (formerly called DOC, now WEB) to allow the three to coexist. > Regrettably, it works best for monstrous great books, not little > critical bits... Also regrettably, it's unreadable! Of all the serious code I've seen (ie, not including things like the Obfuscated C Code Contest), WEB code is easily the least readable. Why? Two big reasons come to mind. One is that what you see usually isn't what you're running: what the .web file contains doesn't correspond to the resulting binary. The change files were a nice idea, but rather misguided. The other is that it's impossible (err, I find it impossible) to keep it straight whether what I'm reading is commentary or code. Any given at-sign symbol seems to have at least four different meanings, depending on the phase of the moon and how I'm holding my mouth. English is usually commentary but sometimes isn't. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu