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

[kassover@jupiter.crd.ge.com (David Kassover)]

In article <5432@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
>In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes:
>
>>For a research project I am collecting information about the risk of
>>choosing the wrong programming language. In particular I am looking
>>for problems that could have been avoided if another (a better)
>>programming language would have been used.
>
>>I know of these three such stories:
>	...
>>     3. The AT&T breakdown a month ago was caused by a break statement
>>	in C. See the following mail (multiple forwarding headers deleted):
>
>What other programming language?  Only one without any GOTO or restricted
>GOTO (e.g. exit, break, ...).  This leaves out Ada!!!!!!
>
>Similar bug in Ada: 	(Cut down for posting, but gives the flavor)
>
>In my limited experience the cases where Ada is introduced into a
>programming environment also introduce lots of other good software
>engineering practices.  For example, lots of people I know who
>program in C don't use LINT.   I view it as a deficiency of management
>and not of the language that they don't use available tools.
 
OK.  First, I apologise for mis-representing the "classic"
FORTRAN goof  (There's one that's actually ambiguous to the
compiler, involving FORMAT statements and Hollerith constants,
but I can never remember it)

Now, AT&T breakdown:
 
You show how this could happen in Ada.  Ok, it could.  But ada
allows one to "name" loops, and use those names in exit
statements, especially useful when you want to break out of an
inner and an outer loop.  In your example, you didn't do so,
since the C code could not.  But you could have.
 
Looking back at the last 20Klines of Ada I've written recently,
I've used named loops roughly twice.  Specifically to avoid
ambiguity to me when I look at the code, but it helps make sure
I did it right, too.
 
You go on to bemoan the lack of use of LINT.  I submit that,
since we're not dependent on underpowered pdp9's or 11's anymore,
then LINT should be built into the compiler, or there as the
default option  (to be turned off at the user's risk)

And onward, to problems that are exacerbated by the language.  

Time and again, my C development people spend oodles of effort
tracking down something that ends up being resolved by
discovering a header file that was changed, but not *all* of the
dependent code was recompilied.  Use make, you say?  Sure, but
someone's got to write the make script, whose language is no gem,
either.
 
Ada's insistence on specification recompile (and lack of a
include processor) cause the dependency tree to be built and
modified automatically.  (in Vax ada, you can enter "foreign
language" object modules into the library, so they, too, can
participate in obsolescence analysis.  I don't know if anyone
else provides this, or how well it works)
 
 
On a par in terms of frequency with the above is the case of the
non-catchalled case statement.  In ada, if you have a case
statement of an enumerated type, and you do not provide a case
for every member of the type or a when others => clause, the
compiler signals an error.  No, this doesn't stop someone putting
a when others => null; in, but most of us either use the compiler
to remind us to put in an appropriate case or cause a fatal error
to occur in the catchall, the theory being that it will blow up
in testing, and the appropriate case added.
 
Finding this thing in C is a bear, especially when, if your code
is like mine, three quarters of it is conditional compile based
on flags set in a header file somewhere.
 
And just as a final note:  I have demonstrated many times that it
is possible to write FORTRAN in Ada.  About the only places I
haven't been able to do so, if I really wanted to, have been APL
and assembler.  That doesn't mean that either Ada or FORTRAN are
valueless.