Re: problems/risks due to programming language, stories requested

[Paul Snively <snorkelwacker!apple!apple.com!chewy@bloom-beacon.mit.edu>]

In article <BILL.90Feb27143004@hcx2.ssd.harris.com> bill@ssd.harris.com 
(Bill Leonard) writes:
> In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald 
Baumgartner) writes:
>            Again it looks like this bug wouldn't have occurred in another
>            programming language.
> 
> I can't resist saying that this last statement seems to me to be utter
> nonsense.  What programming language (read, compiler) can read the
> programmer's mind and tell what he meant?  The use of the "break" 
statement
> was a logic error (actually, it sounds like it was a lack of knowledge of
> the language, since "break" does not apply to "if").  I can't imagine a
> programming language that could discern this type of error.  [If I use
> WHILE instead of IF, for instance, I can expect some things to work and
> some not.  Yet I seriously doubt any compiler could possibly detect this
> error.]
> 
> I certainly think programmers often choose an inappropriate language, 
but I
> shy away from anecdotal stories like these because they seem (to me) to
> spread a lot of misinformation.  Unless you implement a project in 
multiple
> languages, it is nothing more than a guess to say what would have 
happened
> if the project had been implemented in some other language.  Perhaps you
> would have discovered an even more serious flaw in that language, or you
> might simply find it was no better or worse than the one you chose, just
> different.
> 
> Most of the stories I have heard along these lines all struck me as 
missing
> the point: how well was the program tested?  Were there code reviews?
> Design reviews?  All of these techniques are proven to reduce errors.  
Most
> of the errors in these stories (e.g., the infamous dot-versus-comma one)
> should have been found with even rudimentary testing.
> 
> Use of an inappropriate language is no excuse for abandoning other 
techniques
> of good software engineering.

I don't think that anyone's claiming that it is an excuse; I believe the 
point was that some languages applied to some tasks lend themselves to 
error more than another language applied to the same task.  If you wish to 
interpret the above story as a rather pointed jab at the C programming 
language, and object to C being treated that way, that's fine, but please 
just say so.

For what it's worth, my personal opinion is that C lends itself to 
precisely the kinds of errors noted above--when does break work and when 
doesn't it, and why in God's name do you need it in switch statements in 
the first place, etc.  I believe that it's C's historical looseness that 
is simultaneously its greatest weakness, when it leads to errors like 
this, and its greatest strength--C doesn't restrict you; C is mean and 
lean; C is close to the hardware; real programmers use C; even, God help 
us, C is the only language you need!  We all know C programmers whose 
machismo is thus huffed and puffed up (another of my personal opinions is 
that the per capita arrogance of C programmers far outweighs the per 
capita arrogance of any other language-aficionado group).

Now to get back to the important point: what language would have been 
better for the task in question?

Well, I hate to say it, but it's extremely unlikely that such an error 
would have been made in Pascal, since Pascal doesn't require you to 
explicitly break from case...of constructs.

Before the flames start, let me just add: no, I don't necessarily prefer Pascal over C for all tasks.  I generally attempt to choose the right tool for the job, rather than falling into the "when all you have is a hammer, everything looks like a nail" trap.

Standard Disclaimer.