[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems/risks due to programming language, stories requested
In article <BILL.90Feb27143004@hcx2.ssd.harris.com> firstname.lastname@example.org
(Bill Leonard) writes:
> In article <email@example.com> firstname.lastname@example.org.EDU (Gerald
> 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"
> 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
> I certainly think programmers often choose an inappropriate language,
> shy away from anecdotal stories like these because they seem (to me) to
> spread a lot of misinformation. Unless you implement a project in
> languages, it is nothing more than a guess to say what would have
> 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
> Most of the stories I have heard along these lines all struck me as
> the point: how well was the program tested? Were there code reviews?
> Design reviews? All of these techniques are proven to reduce errors.
> 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
> 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.