Nonsense in BYTE reader columns

[Henry Spencer]

> ...[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 "=="?) 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; existing C-oriented tools probably will not work
on it; if they ever start mixing it with normal C they'll have real fun;
if they ever start having to look at normal C they won't know how to cope.

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.

> ...If you prefer
> "real" C, just run the other person's program through a selective pre-
> processor...

How do I run it back again when I want to give my improvements back to him?
For that matter, how do I apply a patch he sends me?

> 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.
-- 
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