A question of style

[T. William Wells]

In article <574 at mars.Morgan.COM> amull at Morgan.COM (Andrew P. Mullhaupt) writes:
: In article <1989Dec4.032918.16550 at twwells.com>, bill at twwells.com (T. William Wells) writes:
: > In article <565 at s5.Morgan.COM> amull at 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 at twwells.com