Nonsense in BYTE reader columns

[Root Boy Jim]

> > ...[redefining C syntax with macros]... The
> > point wasn't that you SHOULD do things this way, but that you COULD.  And
> > there's nothing wrong with someone programming that way, if it increases
> > their efficiency and doesn't hinder the quality of the code...
> 
> Provided that they realize that they're easing their own learning process
> a bit (c'mon, guys, how long does it take competent people to learn how
> to write "{}" and "=="?) ...

That's not the point. 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.

> ... at the price of having their own private dialect of C. 
> In a more general context, yes there *is* something wrong with it:
> the result will be less intelligible to experienced C programmers, should
> they happen to hire any;

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.

> existing C-oriented tools probably will not work on it;

You have a point here. However, maybe the tools should be table driven.

> 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 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. Really now, Henry, you have such a
dim view of people's capabilitys. Do you suggest that Bourne can't
read vanilla C?

> When I first encountered C, about eleven years ago, I did something quite
> similar.  I eventually gave it up.  The benefits were superficial and
> the compatibility hassles weren't worth it.

I would agree with the first point here. 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 you prefer "real" C, just run the other person's program
> > through a selective preprocessor...
> 
> How do I run it back again when I want to give my improvements back to him?

You tell him what a jerk he is for not using your style in the first place :-)
You scored another point. Perhaps you hand tailor your patch for this guy.
Perhaps you replace the entire function. Perhaps you make him do it.
Or perhaps, if you are civic minded, you write an inverse translator.

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

> > That's one of the really wonderful things about C: the
> > preprocessor.  Why not use it?
> 
> Because it can make things harder just as readily as it can make things
> easier.  See the Obfuscated C Contest for some exaggerated but telling
> examples.  Knowing how to use a nifty facility is easy; knowing when *not*
> to use it is harder but more important.

Using the OCC as an example proves nothing. The spirit is completely
different. I agree that the power inherent in CPP tempts one to toy
with the language definition. Usually, people do what they think will
add to the clarity and robustness of their work.

> 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
 
 I like your signature lines. Hope you like Zippy's.

	(Root Boy) Jim Cottrell		<rbj at icst-cmr.arpa>
Here I am at the flea market but nobody is buying my urine sample bottles..