Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!murdu!sue
From: sue@murdu.oz (Sue McPherson)
Newsgroups: comp.software-eng
Subject: Re: problems/risks due to programming language, stories requested
Message-ID: <1820@murdu.oz>
Date: 28 Feb 90 22:18:49 GMT
References: <6960@internal.Apple.COM>
Reply-To: sue@murdu.UUCP (Sue McPherson)
Organization: Software Contracts Group, University of Melbourne, Australia
Lines: 40

>From article <6960@internal.Apple.COM>, by chewy@apple.com (Paul Snively):
>> 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 think its a mistake to think that any language can prevent programming
errors, especially by programmers who do not have a full understanding of
a language.

For instance, I recently helped someone who couldn't work out why a minor 
change to a program caused it to crash, and when he removed the change, it
still crashed.
...
	CHARACTER ARRAY(12)*3
	CHARACTER PATT*3
	INTEGER I
...
	I = 12
10	IF ((ARRAY(I).NE.PATT).AND.(I.GT.0)) THEN
	  I = I - 1
	  GOTO 10
	ENDIF
...
Of course, if PATT isn't in ARRAY it means that the check on ARRAY(0) caused
an access violation which only caused the program to crash when the
"/check=all" option was used to compile.

Its a dumb mistake and its easy to see how it happened but it would be wrong to
say that it was caused by the lack of good control structures in FORTRAN,
just as its a poor excuse to blame C for the mistakes programmers make when
using it.

As the saying goes...

	A BAD WORKMAN BLAMES HIS TOOLS


Sue McPherson
sue@murdu.unimelb.edu.au