hen@bu-cs.BU.EDU (Bill Henneman) (01/11/88)
In article <609@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes > Sorry, but in my opinion the similiarity between "==" and "=" is a >flaw in the language. My attitude towards programming enviroments (languages >comprise part that) is that one aspect the enviroment should provide is >assisting programmers in developing software by insolating them against >common errors they make. "=" in place of "==" is a very common bug I've seen >made by C programmers. Claiming that its the programmer at fault won't, >help you when your software clashes causing major damage (as in a Venus probe >that had a bug in the software to the degree: for i=1.100 in Fortran ). >"An once of prevention is worth a pound of cure." Are there programmers who really have trouble with this? I know a fair number of C programmers (i.e., people who are paid to produce code), and none of us find these kinds of things to be sources of error. Those of us with the most experience with other languages took the longest for that to stop being a source of error - about half a day. By the time we had run the exercises in Chapter 3 of K&R, this sort of error was about as likely as my saying *DO* or *LOOP* when I mean *FOR*. Is my experience unique? Is there something in the air in Boston that makes us immune to this sort of error? Skeptical in Kenmore Square
mcdonald@uxe.cso.uiuc.edu (01/13/88)
The problem with == vs = is not intent of the programmer; it is how long you hold down your finger on the = key! :-)
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (01/13/88)
In article <18515@bu-cs.BU.EDU>, hen@bu-cs.BU.EDU (Bill Henneman) writes: > In article <609@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes paragraph by Eddie Wyatt on programming environments deleted > > Are there programmers who really have trouble with this? I know a > fair number of C programmers (i.e., people who are paid to produce > code), and none of us find these kinds of things to be sources of > error. Those of us with the most experience with other languages took > the longest for that to stop being a source of error - about half a > day. By the time we had run the exercises in Chapter 3 of K&R, this > sort of error was about as likely as my saying *DO* or *LOOP* when I > mean *FOR*. > > Is my experience unique? Is there something in the air in Boston that > makes us immune to this sort of error? > > Skeptical in Kenmore Square Must be the air in Boston :-). I don't think there are many programmers that really have trouble with this (for long), its just when you have been typing at a keyboard for a long time it becomes easier to slip up. I don't believe anyone is immune from this, except maybe Dennis Ritchie :-). How are you certain that these mistakes weren't made? How should a language be designed so that these errors are hard to make (would be an interesting thesis topic)? I'd rather have the power without the syntactic seat belts and have a syntax checker to verify the code. Other common "typos" in C are extra semicolons after if while for and else, dangling elses (many programming languages have this problem), missing parenthesis in expressions resulting in fouled up precedence, using a bitwise or when a logical or was intended, ditto for bitwise and, nesting comments, etc etc. I mentioned in another posting a syntax checker called inspect that I wrote in another article that checked for this sort of stuff in C and C++. I ran it on many different versions of the UNIX operating system, and found bugs in every one of them. There weren't a lot of bugs, though some of them were major problems.
wfp@dasys1.UUCP (01/16/88)
In article <18515@bu-cs.BU.EDU>, hen@bu-cs.BU.EDU (Bill Henneman) writes: > Is my experience unique? Is there something in the air in Boston that > makes us immune to this sort of error? [referring to confusion of "=" and "=="]. You're probably right. I've been working on a C++ project in Route 0x80-land for the past four months (with weekend furloughs :-); I hadn't written any appreciable amount of C for a few years previous to this, and never any C++, but that is one mistake I haven't made yet on this project. My little trick was to tell myself "= means equals, but == means is equal to", or something like that (not an entirely conscious process). But I'm sure the air was the major factor! -- William Phillips {allegra,philabs,cmcl2}!phri\ Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!wfp New York, NY, USA (-: Just say "NO" to OS/2! :-)