Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!husc6!harvard!seismo!mcvax!ukc!reading!minster!nigel
From: nigel@minster.UUCP (nigel)
Newsgroups: net.micro.amiga,net.lang.c
Subject: Re: Nonsense in BYTE reader columns
Message-ID: <827@minster.UUCP>
Date: Wed, 18-Jun-86 18:04:22 EDT
Article-I.D.: minster.827
Posted: Wed Jun 18 18:04:22 1986
Date-Received: Sat, 21-Jun-86 08:20:06 EDT
References: <8606141823.AA12695@pavepaws> <639@ucbcad.BERKELEY.EDU>
Reply-To: nigel@minster.UUCP (nigel)
Organization: University of York, England
Lines: 51
Xref: watmath net.micro.amiga:3678 net.lang.c:9499

In article <639@ucbcad.BERKELEY.EDU> chapman@pavepaws.UUCP (Brent Chapman) writes:
>In article <8606141823.AA12695@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes:
>>
>>	Get a Load of this, everyone (May 1986 Byte)
> 	[lines concerning misinformed Atari fanatic deleted]
>>	The other thing in the BYTE issue that really made me puke was their
>>article "Easy C".  The author attempts to convince the reader that C would
>>be much better if you didn't use it's constructs .. replacing them with
>>#define equivalants which make C look like Pascal.  Next, he'll be telling
>>us not to use pointers.  Give me a break!
>>
>>					-Matt
>
>If I remember correctly, the basic ideas of the article were:
>	1)  We have a group of programmers who don't know C.  (gasp!!! :-)
>	2)  We have a program that (for SOME reason; I don't remember
>	    what it was) MUST be written in C.
>	3)  We don't have time for them to become proficient in C.  (Let's
>	    be honest folks:  C is NOT the easiest language in the world
>	    when you're first learning it.)
>	4)  This is what we did to ease the transition.
>
>I felt that the article was a fine testimony to the flexibility of C.  The
....
>
>Brent

The apporach of 'sugaring' C is not unusual - have you looked at the source
code for sh? What I felt was wrong with the article was the "lets invent
a macro substitution for every construct whether it needs one or not"
attitude. Why, for instance, does <= need to be defined as LE ?? Very shortly
we get

if ((c >= 'a' && c <= 'z')||(c >= 'A' && c <= 'Z'))

replaced by

if ((c GE 'a' AND c LE 'z') OR (c GE 'A' AND c LE 'Z'))

This looks more like FORTRAN that Pascal ... now that I do take exception to.
The <= construct (and related ones) are fine as they are. I also doubt that
BAND is more meaningful for bitwise and than &. Finally, I we wish to make
C look like Pascal, try

#define THEN

allowing

IF (((c >= 'a') AND (c <= 'z'))OR((c >= 'A') AND (c <= 'Z'))) THEN

which is correct Pascal (or if it isn't you get my drift).