paul@dual.UUCP (Baker) (03/19/85)
> > I was reading Creative Computing when I saw the most bogus C programming > > example. The author was comparing C to Basic- > > Basic: if A=1 and B=1 goto 104950393040 [:-> > > C: if (A==1 & B==1) foobar(); > > Which works, of course, but it was clear from the context that the author > > thought that '&' and logical AND were identical!!!! -- Mark Roddy > > It doesn't work if A == 1 and B == 3. It calls foobar when it shouldn't. But then the whole point of C is to make it easy to commit errors which superficially look correct, compile without a whimper and yet are totally wrong. For example "if (X!=1)" ... compiles just as well as "if (x|=1)". On many terminals "|" and "!" are almost indistinguishable. "if (x<>1) would have been incredibly easier to understand, but, oh no, other people had used this and so was obviously unacceptable. Paul Wilcox-Baker.
berke@csd2.UUCP (Wayne Berke) (03/22/85)
> > > I was reading Creative Computing when I saw the most bogus C programming > > > example. The author was comparing C to Basic- > > > Basic: if A=1 and B=1 goto 104950393040 [:-> > > > C: if (A==1 & B==1) foobar(); > > > Which works, of course, but it was clear from the context that the author > > > thought that '&' and logical AND were identical!!!! -- Mark Roddy > > > > It doesn't work if A == 1 and B == 3. It calls foobar when it shouldn't. It sure does work. It simplifies to if (1==1 & 3==1) foobar() if (TRUE & FALSE) foobar() if (0x1 & 0x0) foobar() if (FALSE) foobar() So foobar is correctly not invoked.
seifert@mako.UUCP (Snoopy) (03/22/85)
In article <967@dual.UUCP> paul@dual.UUCP (Baker) writes: >But then the whole point of C is to make it easy to commit errors which >superficially look correct, compile without a whimper and yet are totally >wrong. For example "if (X!=1)" ... compiles just as well as "if (x|=1)". >On many terminals "|" and "!" are almost indistinguishable. "if (x<>1) >would have been incredibly easier to understand, but, oh no, other people >had used this and so was obviously unacceptable. Why flame C because you have a brain-damaged terminal? Many pairs of characters are hard to distinguish on various terminals, but that doesn't mean the language is bad. I'd hate to hear what you must think of APL. If you don't like C, fine. Don't use it. Use some other language. _____ |___| the Bavarian Beagle _|___|_ Snoopy \_____/ tektronix!mako!seifert \___/ If God had intended Man to Smoke, He would have set him on Fire. -the fortune AI project
sde@Mitre-Bedford (03/22/85)
Actually, there are those of who, disliking both the "="/"==" closeness and the "!="/"|=" closeness, use "EQ" for "==" and "NE" for "!=", which C allows by means of #define. David sde@mitre-bedford P.S. I do, however, agree that it was ergonomically foolish to count relative uses of assignment vs. comparison to come up with =/== instead of :=/=. How many hours of debug time (and how many debug keystrokes) does it take, after all, to use up the marginal saving of some keystrokes in initial entry?
throopw@rtp47.UUCP (Wayne Throop) (03/24/85)
> Actually, there are those of who, disliking both the "="/"==" closeness > and the "!="/"|=" closeness, use "EQ" for "==" and "NE" for "!=", which > C allows by means of #define. > > David sde@mitre-bedford > > P.S. I do, however, agree that it was ergonomically foolish to count > relative uses of assignment vs. comparison to come up with =/== instead > of :=/=. How many hours of debug time (and how many debug keystrokes) > does it take, after all, to use up the marginal saving of some keystrokes in > initial entry? > It seems to me that the normally-cited "save keystrokes" reason for the =/== choice cannot be correct. If it were, wouldn't the choice for the &/&& and |/|| operators be reversed? &&'s are much more common than &'s in almost all C code I have seen. It also seems clear that saving keystrokes is almost never a valid concern. What needs to be optimized is readability. Even in the case of my own code, let alone others, I read it much more often than I write it.
cottrell@NBS-VMS (03/26/85)
/* > It seems to me that the normally-cited "save keystrokes" reason for > the =/== choice cannot be correct. If it were, wouldn't the choice for > the &/&& and |/|| operators be reversed? &&'s are much more common than > &'s in almost all C code I have seen. It depends on how you write code. I do lotsa bit twiddling, therefore I got lotsa `&' & `|'. I avoid multiple condition tests, therefore I seldom have `&&' & `||'. > It also seems clear that saving keystrokes is almost never a valid concern. > What needs to be optimized is readability. Even in the case of my own > code, let alone others, I read it much more often than I write it. There are thos of us who consider verbosity the scourge of readability. `Begin' & `end', e.g.,just clutter up the listing & spread it out more. I HAVE been bitten by saying `if (c = NL)' a lot tho. Oh well. jim cottrell@nbs */
ndiamond@watdaisy.UUCP (Norman Diamond) (03/26/85)
> P.S. I do, however, agree that it was ergonomically foolish to count > relative uses of assignment vs. comparison to come up with =/== instead > of :=/=. How many hours of debug time (and how many debug keystrokes) > does it take, after all, to use up the marginal saving of some keystrokes in > initial entry? > -- David sde@mitre-bedford You forgot the fundamental philosophy of C. There's no such thing as a mistake; there's only a different and equally valid program. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
riddle@ut-sally.UUCP (Prentiss Riddle) (03/27/85)
> It seems to me that the normally-cited "save keystrokes" reason for > the =/== choice cannot be correct... Wasn't "==" chosen for its obvious analogy to "!=", "<=", and ">=" ? That's what I've always assumed, at least. --- Prentiss Riddle ("Aprendiz de todo, maestro de nada.") --- {ihnp4,harvard,seismo,gatech,ctvax}!ut-sally!riddle --- riddle@ut-sally.UUCP, riddle@ut-sally.ARPA, riddle%zotz@ut-sally
peters@cubsvax.UUCP (Peter S. Shenkin) (03/28/85)
>> It seems to me that the normally-cited "save keystrokes" reason for >> the =/== choice cannot be correct... > >Wasn't "==" chosen for its obvious analogy to "!=", "<=", and ">=" ? >That's what I've always assumed, at least. > The "save keystrokes" assumption comes from p17 of K&R: Since assignment is about twice as frequent as equality testing in typical C programs, it's appropriate that the operator be half as long. ...which I never was tempted to take as anything but a cute little quip, and perhaps a subtle dig at PASCAL. In these latter days, it would no doubt be postpended with a ":-)". In any case, I apologise for contributing to the discussion. If the truth be known, I'm very bored with it by now.
mouli@cavell.UUCP (Bopsi ChandraMouli) (03/29/85)
In article <1401@ut-sally.UUCP> riddle@ut-sally.UUCP (Prentiss Riddle) writes: >> It seems to me that the normally-cited "save keystrokes" reason for >> the =/== choice cannot be correct... > >Wasn't "==" chosen for its obvious analogy to "!=", "<=", and ">=" ? >That's what I've always assumed, at least. The "obvious" analogy goes like this. :=) <= -- less than OR equal >= -- Greater than OR equal != -- not OR equal (not quite right!) == -- equal OR equal or more appropriately assign OR assign --------------------------------------- ihnp4!alberta!cavell!mouli
ndiamond@watdaisy.UUCP (Norman Diamond) (03/29/85)
> The "save keystrokes" assumption comes from p17 of K&R: > > Since assignment is about twice as frequent as equality testing > in typical C programs, it's appropriate that the operator be > half as long. > > ...which I never was tempted to take as anything but a cute little quip, > and perhaps a subtle dig at PASCAL. In these latter days, it would > no doubt be postpended with a ":-)". It may have been a subtle dig at ALGOL, but the inventors of C and PASCAL probably knew very little about each other at the time they made such decisions. In fact I think C predates PASCAL by a year or two, but don't know how to tell for sure. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
root@bu-cs.UUCP (Barry Shein) (03/31/85)
All this griping about accidently typing things like if(c = NL) when the user meant == reminds me of an old joke around here about another bell labs language. We used to tell students that you could put on a pair of golf shoes, jump all over a keypunch card (told you it was old) and it would be a legal SNOBOL program...heck, ' ' was an operator! I personally doubt anyone will ever design a language that did much to prevent typos by it's syntax. Structure editors might be a better solution although it would have to be pretty clever to pick up the above error (DWIM.) Besides, syntax errors are annoying while semantic errors (the above falls in between) are where the real problems lie, I guess the former are easier to gripe about from an armchair so they get more attention. -Barry Shein, Boston University
brownc@utah-cs.UUCP (Eric C. Brown) (04/01/85)
In article <325@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: >All this griping about accidently typing things like > > if(c = NL) Well, the Wizard C compiler for the IBM PC prints a warning message: Warning: Possibly incorrect assignment with that line. If you want it to shut up, then use if ((c = NL) != 0) or whatever. All C compilers are not created equal: some compilers check to see if what you typed made any sense at all. Eric C. Brown Execute People, not Programs!
mwm@ucbtopaz.CC.Berkeley.ARPA (04/01/85)
In article <325@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: >We used to tell students >that you could put on a pair of golf shoes, jump all over a >keypunch card (told you it was old) and it would be a legal >SNOBOL program...heck, ' ' was an operator! No, ' ' was not "an" operator, it was *three* operators: string concatenation, pattern concatenation, and pattern match. <mike
john@x.UUCP (John Woods) (04/03/85)
> > You forgot the fundamental philosophy of C. There's no such thing as a > mistake; there's only a different and equally valid program. > Norman Diamond Thank Goodness for PASCAL, in which it is Impossible to write an incorrect program! And remember, with each copy of the PASCAL Report you buy, you also get a shareholder certificate for the Brooklyn Bridge! -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA Think of it as "evolution inaction". There are no unintentional spelling errors in this article.
ndiamond@watdaisy.UUCP (Norman Diamond) (04/08/85)
> Thank Goodness for PASCAL, in which it is Impossible to write an incorrect > program! And remember, with each copy of the PASCAL Report you buy, you > also get a shareholder certificate for the Brooklyn Bridge! If the compiler catches 90% of my typos instead of 50%, because 90% instead of 50% result in compile-time errors, then I save a lot of time on those searches for little irritating bugs. At least, bigger bugs aren't as irritating (as well as being less frequent). -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."