Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtech.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!tektronix!hplabs!amdahl!rtech!jas
From: jas@rtech.ARPA (Jim Shankland)
Newsgroups: net.lang.c
Subject: Re: C Indentation Survey Results (long...)
Message-ID: <343@rtech.ARPA>
Date: Wed, 1-May-85 13:21:24 EDT
Article-I.D.: rtech.343
Posted: Wed May  1 13:21:24 1985
Date-Received: Sat, 18-May-85 00:38:51 EDT
References: <9930@brl-tgr.ARPA> <381@busch.UUCP> <5497@utzoo.UUCP> <5548@utzoo.UUCP>
Organization: Relational Technology, Berkeley CA
Lines: 37

Henry Spencer has concisely and eloquently summed up the case against
prettyprinters:

> 	A paragrapher cannot judge the programmer's intent, and hence cannot
> 	do as good a job of displaying it as the programmer can.
> 	Paragraphers should be used to deal with emergencies, not as a
> 	substitute for doing it right the first time.

But I don't buy it.  In most cases, the program's syntax DOES (or should)
accurately reflect the programmer's intent.  In cases when it doesn't,
variant formatting may hinder, rather than help, comprehension:  when
a program's syntactic structure is clearly and consistently reflected
in a display style selected by the reader of the code, the attention
of the reader can focus on the MEANING of the code:  the "programmer's
intent."

Given the choice between seeing a piece of code displayed in a syntactically
consistent way selected by me, and seeing the code displayed in a
syntactically variant way selected by the original programmer, with
the variants intended to give me clues about the programmer's intent,
I will gladly select the former option.

Let me restate my case by altering Henry's statement above to make
a (specious) argument against the use of high-level languages:

	A compiler cannot judge the programmer's intent, and
	hence cannot do as good a job of generating code as the
	programmer can.  High-level languages should be used
	only for emergencies, and are no substitute for the
	programmer's hand-coding the algorithm in the first place.

Jim Shankland
Relational Technnology, Inc.
ucbvax!mtxinu!rtech!jas
ihnp4!pegasus!rtech!jas

The opinions expressed above may not be shared by my dog.