woody@juliet.caltech.edu (William E. Woody) (05/06/86)
I understand that it would be very useful to have /\, \/, #import, ^^, &#, and any other pair of non-alphanumeric character represent some special operation that would be useful (and even _important_) for some application or another. HOWEVER, as useful it would be to include other operators, Remember What Happened to PL/1. Because everyone in the design committee wanted something and no-one wanted to say no! we stop adding commands/functions/operators here, I have never seen a full implementation of PL/1 on any machine--the original language specifications are too bloody big to have a compiler fit on a single vax. I Like C to be reasonably easy to learn _and_ extremely powerful, as well. But if we tack on new commands and operators at will, then everyone's program will be a winner in the Obfuscated C contest! - William Woody NET Woody%Romeo@Hamlet.Caltech.Edu USNAIL 1-54 Lloyd, Caltech / Pasadena, CA 91126 Boy I can feel the flames now! :-)
chongo@nsc.UUCP (Landon Noll) (05/12/86)
In article woody@juliet.caltech.edu (William E. Woody) writes: > I Like C to be reasonably easy to learn _and_ extremely powerful, as well. >But if we tack on new commands and operators at will, then everyone's program >will be a winner in the Obfuscated C contest! > > - William Woody I agree. Most suggestions of "new-and-improved" C features try to make C into some other language. I was glad to see Ansi-C standard drafts did not go Hog-wild (as in J. Poornelly C) with features, though some of them go too far. When you want to add something to C, ask yourself: Does the power I gain justify the additional complexity of the compiler? Does it break existing C programs? Does it add something that was not already there in another form? Last, consider what this "new" feature will do to the complexity of C source. Consider the potential abuse of the "feature". If 1986's entries any any judge, we nearly have enough of these problems already... chongo <CONTEST ENDS MAY 30! HAVE YOU SENT IN YOUR ENTRY?> /\cc/\
d25001@mcomp.UUCP (05/19/86)
> > HOWEVER, as useful it would be to include other operators, Remember What >Happened to PL/1. Because everyone in the design committee wanted something >and no-one wanted to say no! we stop adding commands/functions/operators >here, I have never seen a full implementation of PL/1 on any machine--the >original language specifications are too bloody big to have a compiler fit on a single vax. > - William Woody > NET Woody%Romeo@Hamlet.Caltech.Edu > USNAIL 1-54 Lloyd, Caltech / Pasadena, CA 91126 That's what comes of trying to put a big language on a small machine. Carrington Dixon