Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!ukma!uflorida!novavax!twwells!bill From: bill@twwells.com (T. William Wells) Newsgroups: comp.lang.c Subject: Re: A question of style Message-ID: <1989Dec7.193140.9751@twwells.com> Date: 7 Dec 89 19:31:40 GMT References: <547@mars.Morgan.COM> <1989Nov30.001947.14883@aqdata.uucp> <1989Dec4.032918.16550@twwells.com> <574@mars.Morgan.COM> Organization: None, Ft. Lauderdale, FL Lines: 120 In article <574@mars.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes: : In article <1989Dec4.032918.16550@twwells.com>, bill@twwells.com (T. William Wells) writes: : > In article <565@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) : > [presents his subjective judgements as relevant to the discussion.] : : My 'readability ethic' is perhaps evident in the analogy between : reading a newspaper and reading a program; activities which shouldn't : be as far apart as they presently seem. Journalists and newspaper : editors live and die by achieving the widest possible readability, : (as well as by advertising gimmicks...) and perhaps we might profit : by thinking about how this comes about. Try substituting the words : 'C program' for 'newspaper', 'statement' for 'sentence', and : 'preprocessing' for 'typesetting' in the following: There is a fundamental flaw in the analogy. Newspapers and other publications today, unfortunately, tend to try to widen their readership by pandering to the semi-illiterates in their potential audience. Computer programs should try to widen their readership by being valuable to those who can know how to use them. These lead to radically different views on what makes the thing more readable. : Try substituting the words : 'C program' for 'newspaper', 'statement' for 'sentence', and : 'preprocessing' for 'typesetting' in the following: : : When you read a newspaper, there's something dreadfully wrong : if your first impression is of cleverly and compactly punctuated : sentences with new and interesting typesetting. The punctuation and : typesetting are important, but only so far as they are needed to : determine meaning, and assist the human reader to correctly grasp it. But I certainly won't disagree with the above. : > Sorry buddy, but your judgements are not mine. Moreoever, while : > some of your conclusions are valid, basing them on subjective : > judgements makes them appear less valid. : > : > For example, : > : > "There are no good excuses for the comma operator because : > it masquerades as true concurrent assignment where it is a : > poor relation of it." : > : > Maybe you think that the comma operator looks like concurrent : > assignment. If so, you need to work harder at disentangling your : > previous experience from your C programming. Many, perhaps most, : > C programmers don't ever think of concurrent assignment when : > seeing the comma operator. Certainly experienced C programmers : > don't. : : I don't think the standard of readability is wide enough if : only by removing 'previous experience' can we understand C programs. Eh? I didn't say "remove previous experience". The point I was making is that C programming is its own unique thing. While it has much in common with some other activities, it is also different in many ways. It is a mistake to drag in concepts from other activities that are not applicable to C programming. C can not be profitably made to look like other languages by cosmetic means. Nor by applying irrelevant concepts in your understanding of it. Doing the latter will just lead to confusion. : Also: I disagree. Comma clauses which occur as "re-initializations" : in for constructs are often a form of concurrent assignment. What? They are nothing of the sort. It is true that some compilers can take advantage of the fact that certain uses of the comma operator can, though there is an implied sequence, be done concurrently. But there is nothing special about the comma operator in that respect. ++i, ++j is *not* concurrent. It is sequential. It may happen that the machine can do them concurrently. If so, it has to act *as if* they were done sequentially. But the fact that they might be processed concurrently does not change the fact that the expression is conceptually sequential. To think of it as concurrent is an error. : Now it really doesn't matter what the programmer thinks : when he writes the code, (most of the RISC architectures had to do away : with the RPM - 'read programmer's mind' instruction), it matters what : is written. And what is written IS SEQUENTIAL. : > : Now with real concurrent assignment, you : > : really can put your loop invariant maintenance in one place: : > : : > : (i++ , j--) : > : : > : can be replaced by the much more attractive: : > : : > : (i, j) := (i + 1, j - 1) : > : > Yet again we have a very subjective judgement, one which I very : > much disagree with. In fact, I'd say that the latter is defective : > on more than one level. Besides the extraneous characters needed : > to express a much simpler idea, you have interleaved two distinct : > ideas, incrementing `i' and decrementing 'j'; this sort of thing : > leads to decreased understanding. : : Finally - the real nitty-gritty: : : You can disagree all you want, but there is a reason that the : concurrent assignment is preferable to the comma clause, and it : has nothing to do with counting characters. It has to do with : the putative role of the given expression as establishing a loop : invariant. But the notion that taking ++i, --j, a simple, easy to understand expression, and complexifying it into (i, j) := (i + 1, j - 1), in the interests of "put[ting] your loop invariant maintenance in one place", is indefensible. It is already *in* one place, the third expression of the for statement. --- Bill { uunet | novavax | ankh | sunvice } !twwells!bill bill@twwells.com