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

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

In article <5464@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 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.
>
"Oodles" is a rather imprecise term.  I apologize.  But you
aren't here.  Almost time I visit my development people, they are
chasing some sort of bug that was traced to this case, or a
missing catchall.  I may have sampling error problems, I admit it.
>>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 your compiler has a bug (Since Ada is thoroughly standardized,
one standard, no extensions, no subsets) then you should get it
fixed or get a different compiler.

>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.
>...
Well, you're there, and I'm not.  But attempting to do a
professional job with amateur's tools, or amateur quality tools,
is likely to be frustrating, among other things.  This is not a
problem with the language, it's a problem with the implementation
your stuck with.


By the way, the product line I am dealing with is supported on
more than 20 different operating systems, only some of which are
Unix, or Unix-like, some of which do not offer a make-analog, and
even of the ones which do, the make scripts have to be (only
sometimes subtly) different.  I simply do not have time, nor the
charter, to implement make for everybody
>
>>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.
>...
No, I didn't write incomplete code and wait for the compiler to
catch it.  (I've used this technique elsewhere, though).  It is
common, in the ada I have seen, to define in a package
specification an enumerated type.  Later on, someone adds an
element to the type.  (e.g. support for a different type of data
structure, or even, as is the case, add a new package to the
system.  (this system keeps track of the names of it's packages,
in order to generate traceback information during runtime user
errors))

The code in the package body contains a case statement on the
enumerated type.  It was not created incomplete, but it was
RENDERED incomplete by the insertion of a new element.  Since
recompilation is of this body is forced, without having to
remember to modify the make script (we've already forgotten to
modify the package body, remember), this error is fixed before
the module gets out of unit test.

this is not to say that the compilable code in the case statement
is not erroneous, but falling off the end of the case statement
is probably at least as bad.  That is, some human has to exert
effort to allow the case statement to be fallen through, rather
than it being allowed to happen.
>
>If it happens often, adopt a coding style to minimize it, always
>put "default: abort();" in your switch statements.
>
>...
This is the real world.  I have little time to fight with my
people over personal style, and I don't want to be viewed as a
tin pot tyrant over stylistic issues.  My concerns are getting
the product out there, with as few errors as possible.  Ada
appears to help in this regard more than C does.  I'm sure you
and your employers have a somewhat different agenda.
 

Dave Kassover