Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: Nonsense in BYTE reader columns
Message-ID: <6874@utzoo.UUCP>
Date: Mon, 30-Jun-86 18:57:53 EDT
Article-I.D.: utzoo.6874
Posted: Mon Jun 30 18:57:53 1986
Date-Received: Mon, 30-Jun-86 18:57:53 EDT
References: <1726@brl-smoke.ARPA>
Organization: U of Toronto Zoology
Lines: 77

> ... The one statement model is a deficient one. If braces
> were always required, the difference would be syntactic only. The attempt
> was to make C more robust by limiting the possibility of error.

So say "we always write the braces".  This limits the possibility of error
*without* inventing new syntax.

> Who are we kidding? If you can read one dialect, you can read them all,
> at least any reasonable attempt. Everyone's personal style creates
> another `dialect' if you will. It's not that big of a deal.

If you can read one dialect, you can read them all... but not as easily,
confidently, and quickly.  If you can read English you can read Pig Latin,
but nobody would tolerate documentation written in Pig Latin.  It may be
what you prefer for your own private notes, but it is inappropriate for
something that other people have to read.

> > existing C-oriented tools probably will not work on it;
> 
> You have a point here. However, maybe the tools should be table driven.

He who thinks that it's easy to build tools, table-driven or otherwise,
that can cope with the full bizarreness of the preprocessor should try it.

> > if they ever start mixing it with normal C they'll have real fun;
> 
> Yes and no. While it is often claimed that one should be consistent in
> one's coding style, often several people (including later incarnations
> of yourself) work on a program or project. If you modify your old code
> do you slip back into the bad habits you grew out of?

If you modify code in a different style, you preserve that style.  Mixing
styles interferes with comprehension much more drastically than being
consistent in using an odd style.  It took me quite a while to learn this.

> > if they ever start having to look at normal C they won't know how to cope.
> 
> People who have enuf gumption to attempt to change things will also have
> enuf smarts to make the adjustment...Do you suggest that Bourne can't
> read vanilla C?

If he spent a couple of years working entirely in Bournebol, I bet he
couldn't read vanilla C nearly as well as if he'd worked in it.  And he
learned vanilla C first, I'd guess, whereas these people are tinkering with
the syntax *not* because they feel like being new and original but because
they don't want to learn vanilla C.

> ... Really now, Henry, you have such a dim view of people's capabilitys...

As a professional, it's my job to take a slightly dim view of the
capabilities of the people who will look at my code next.  If I am wrong
in doing so, so much the better!  This is a much happier situation than
what happens if I *overestimate* their capabilities.

> ...In the end, it is a big pain to
> maintain a whole other set of standards that mean little to anyone but
> oneself. On the other hand, one must please oneself.

If one is programming solely for oneself, true.  If somebody else is
paying for it, there may be a few other considerations involved.

> [feeding back changes after preprocessing to eliminate style variation]
> ... if you are civic minded, you write an inverse translator.

Life is too short to write inverse translators for everything.

> > For that matter, how do I apply a patch he sends me?
>  
> Run the patches thru the preprocessor.

This gets tedious and inconvenient very quickly.  Ask anyone who's tried it.
I know of cases where sites have abandoned entire software packages because
of this.
-- 
Usenet(n): AT&T scheme to earn
revenue from otherwise-unused	Henry Spencer @ U of Toronto Zoology
late-night phone capacity.	{allegra,ihnp4,decvax,pyramid}!utzoo!henry