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).
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!
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
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.
rbj@icst-cmr (Root Boy Jim) (06/27/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 "=="?) ... 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@icst-cmr.arpa> Here I am at the flea market but nobody is buying my urine sample bottles..
henry@utzoo.UUCP (Henry Spencer) (07/01/86)
> ... 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