dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/14/86)
Get a Load of this, everyone (May 1986 Byte, pg 18) "Inside, there is very little support for the unbound power of the 68000. In the low-resolution mode, those great graphics chips steal almost 75 percent (Yes!) of the possible CPU time that could be used for other real-computer things" -Mike M Farnsworth Somebody educate this guy... please... and That's only 1/10 of the nonsense he said in his letter in BYTE. 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
chapman@pavepaws.berkeley.edu (Brent Chapman) (06/15/86)
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 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. If you prefer "real" C, just run the other person's program through a selective pre- processor. That's one of the really wonderful things about C: the preprocessor. Why not use it? Brent -- Brent Chapman chapman@pavepaws.berkeley.edu ucbvax!pavepaws!chapman TANSTAAFL! (There Ain't No Such Thing As A Free Lunch!)
nigel@minster.UUCP (nigel) (06/19/86)
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).
rico@oscvax.UUCP (06/19/86)
In article <8606141823.AA12695@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU.UUCP writes: > > Get a Load of this, everyone (May 1986 Byte, pg 18) > >"Inside, there is very little support for the unbound power of the >68000. In the low-resolution mode, those great graphics chips steal >almost 75 percent (Yes!) of the possible CPU time that could be >used for other real-computer things" -Mike M Farnsworth > > Somebody educate this guy... please... and That's only 1/10 of the >nonsense he said in his letter in BYTE. I saw this too, (as I'm sure many others did) and I was more than a little bit peeved, not so much at this guy because, well, idiots will be idiots (or rather, ignorants will be ignorant). What really peeves me is that BYTE would let such garbage be printed in the first place... isn't that what technical editors are for? I'm sure Mr. Farnsworth has a head on his shoulders, I hope that next time he uses it to do a little research before writing a loud letter. -Rico Who? Me? I was obviously insane at the time... DISCLAIMER: This letter isn't The Science Centre's fault, leave them alone.
jwp@sdchem.UUCP (John Pierce) (06/19/86)
> I felt that the article was a fine testimony to the flexibility of C. The > point wasn't that you SHOULD do things this way, but that you COULD. Rumor has it that they're now negotiating with AT&T for permission to publish elected pieces of the Bourne shell source. That'll not only be a fine testimony to C's flexibility, but also a useful public service as an aid in retraining all the poor algol hackers who're sort of left out in the cold these days... -- John Pierce Chemistry Dept, B-032 jwp%chem@sdcsvax.ucsd.edu University of California, San Diego sdcsvax!sdchem!jwp La Jolla, CA 92093 +1 619 452 4016
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/19/86)
In article <827@minster.UUCP> nigel@minster.UUCP (nigel) writes: >The apporach of 'sugaring' C is not unusual - have you looked at the source >code for sh? Practically every UNIX system programmer I know couldn't STAND Bourne's pseudo Algol-68 (also used in "adb"). Fortunately this was fixed in SVR2 (I think Dave Korn did the clean-up). >This looks more like FORTRAN that Pascal ... now that I do take exception to. If you want Pascal, use Pascal. Not looking like Pascal is not a language deficiency!
jimm@amiga.UUCP (Jim Mackraz) (06/22/86)
In article <422@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes: >In article <8606141823.AA12695@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU.UUCP writes: >> >> Get a Load of this, everyone (May 1986 Byte, pg 18) >> ... > >I saw this too, (as I'm sure many others did) and I was more than a little >bit peeved, not so much at this guy because, well, idiots will be idiots >(or rather, ignorants will be ignorant). What really peeves me is that >BYTE would let such garbage be printed in the first place... isn't that >what technical editors are for? > I didn't see it first hand, but as I understand it the weeks following the publication of this letter were filled with lambasting on BIX (the BYTE bulletin board). I'm sure BYTE has been wised up. Let's hear it for the good guys (us) and let's let this letter drop. jimm
ltf@well.UUCP (06/23/86)
UUCP> Sender: Reply-To: ltf@well.UUCP (Lance T Franklin) Followup-To: Distribution: Organization: Whole Earth Lectronic Link, Sausalito CA Keywords: In article <1328@amiga.amiga.UUCP> jimm@homer.UUCP (Jim Mackraz) writes: >In article <422@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes: >>In article <8606141823.AA12695@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU.UUCP w rites: >>> >>> Get a Load of this, everyone (May 1986 Byte, pg 18) >>> ... >> >>I saw this too, (as I'm sure many others did) and I was more than a little >>bit peeved, not so much at this guy because, well, idiots will be idiots >>(or rather, ignorants will be ignorant). What really peeves me is that >>BYTE would let such garbage be printed in the first place... isn't that >>what technical editors are for? >> > >I didn't see it first hand, but as I understand it the weeks following >the publication of this letter were filled with lambasting on BIX (the >BYTE bulletin board). I'm sure BYTE has been wised up. > >Let's hear it for the good guys (us) and let's let this letter drop. > > jimm Should be interesting to see if that "lambasting" ever shows up in the "Best of BIX" that Byte publishes every issue. I'm not planning on betting any money on it. Lance Franklin
henry@utzoo.UUCP (Henry Spencer) (06/24/86)
> ...[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
mmeyer@ti-csl (06/24/86)
>>This looks more like FORTRAN that Pascal ... now that I do take exception to. >If you want Pascal, use Pascal. Not looking like Pascal is not >a language deficiency! But looking like FORTRAN >is<, that's his point. Mark Meyer (mmeyer@ti-csl) The above opinions are MINE, all MINE! Ahahahahahahahaaaaa!!!
peters@cubsvax.UUCP (06/25/86)
In article <utzoo.6849> henry@utzoo.UUCP (Henry Spencer) writes: >> ...[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; ... [more good points] Just a reminder that the possibility of this sort of usage is touted by K&R as a virtue of the C preprocessor; pp86-87: For example, Algol fans can say #define then #define begin { #define end ;} and then write if ( i < 0 ) then begin a = 1; b = 2; end Most of us agree that this is a bad idea, for the reasons mentioned; however, it's not obvious that it's a bad idea. That's only become clear by dint of peoples' experience with (other peoples') code written in this fashion. Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
nigel@minster.UUCP (nigel) (06/26/86)
In article <1502@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <827@minster.UUCP> nigel@minster.UUCP (nigel) writes: >>The apporach of 'sugaring' C is not unusual - have you looked at the source >>code for sh? > >Practically every UNIX system programmer I know couldn't STAND >Bourne's pseudo Algol-68 (also used in "adb"). Fortunately >this was fixed in SVR2 (I think Dave Korn did the clean-up). > Read my original article carefully; I pass no comment on the readability of sh - merely that sugaring was used. >>This looks more like FORTRAN that Pascal ... now that I do take exception to. > >If you want Pascal, use Pascal. Not looking like Pascal is not >a language deficiency! Looking like FORTRAN is. A Pascal programmer moving over to C does not need help with comprehension of operators such as <=, as they occur in Pascal.