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

[hammondr@sunroof.crd.ge.com (Richard A Hammond)]

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.

RE: AT&T example
OK folks, I was not trying to say that C was as good as Ada,
I merely pointed out that in both C and Ada one could have a
legal program that had a restricted goto (C "break", Ada "exit")
inside an if, and that neither language's compilers could detect
whether the programmer really wanted that or not.  This, to my
mind, makes the example not fit the class that was requested,
of cases where a different language would have prevented the
problem.


In article <5458@crdgw1.crd.ge.com> kassover@jupiter.crd.ge.com (David Kassover) writes:
...
>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.

The oodles of time is an exageration, since, painful though it
might be, writing the make script would solve the problem once
and for all.  This suggests that the cost to find the numerous
problems is less than to write a make script.  By the way, there are
tools available to automatically generate most of the makefile.
Besides, if you have a make script you can cause lint to run
automatically, which is a nice side benefit.

>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)
 
And it is a real pain when the compiler has a bug in the implementation,
as does the Ada compiler we're using.  If you change a generic body
it messes up its internal information and you end up recompiling
everything, so we end up avoiding the built-in "make" of Ada and
writing make scripts to get the proper recompilations done.
Maintaining the make scripts costs less time than recompiling
everything every time you change a generic body.
Building everything into the compiler does have disadvantages.

>On a par in terms of frequency with the above is the case of the
>non-catchalled case statement. ...
 
>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.

So, in Ada you either write incomplete code (because the compiler
will catch it) or you raise an exception(I imagine) in the "others"
case.  I don't see why you can't  adopt the second solution in C.
If it happens often, adopt a coding style to minimize it, always
put "default: abort();" in your switch statements.

Your complaints remind me of the old chinese saying (Rich's paraphrase)
Fooled once, shame on the language which fooled you.
Fooled twice, shame on you.

Rich Hammond