problems/risks due to programming language

[Scott MacHaffie]

In article <8103 at hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu at hubcap.clemson.edu writes:
>   the NEXT case.  In other words, C requires the programmer to use a
>   dangerous construct on a routine basis.

(the dangerous construct is the "break" statement)
But if "break" were renamed "end case" then there wouldn't be any problem?

>   code associated with the else part.  Thus, we have an inconsistency
>   in C's design: with one flow-of-control construct (the switch), it is
>   necessary to use a dangerous GOTO to achieve normal processing, whereas

No, it is necessary to use a statement to indicate that the current case
statement is finished...like an "end case" or the next "when => " in ADA.

>   with a similar flow-of-control construct (the if-else), the default is
>   reversed.  Given such a language design, it should not surprise anyone
>   that programmers become confused, particularly when the constructs are
>   being used together. 

Some programmers become confused -- good programmers, and software engineers,
don't.

>   specified situation has been executed.  Ada also provides the exit
>   statement, a restricted GOTO which permits a loop to be exited early,
>   but this construct is not used (as is C's break) on a routine basis.  

In all the ADA I have seen, the preferred looping construct is a "loop"
with exit statements sprinkled throughout it. On the other hand, C's
"break" statement is only occasionally used to exit a loop prematurely.

>> 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.

I don't use LINT. I use compilers that check certain things I want checked,
like "no prototypes in scope".  LINT does not catch the kinds of mistakes
that I make.  How many ADA programmers do you know of use LINT?

>   This is certainly true; Brooks and others have noted that the good
>   software engineering practices which are routinely introduced in
>   conjunction with the Ada language are responsible for more of the 
>   resulting improvements than the fact that the Ada language was

Well, these practices are certainly NOT being introduced in the universities
(at least not here).

>   introduced.  However, we cannot disregard that fact that Ada was
>   specifically designed to provide maximal support for the software 
>   engineering process.  C, on the other hand, was designed to provide

No, ADA was designed to have everything. The fact that it (or some subset
of it) can be used to do software engineering doesn't mean it was designed
to do it.  Software engineering can be done in any language, including C.

>   maximal support for the compilation process.  Since compilers and 
>   the CPU power required to operate them come far more cheaply than 
>   programmers, and especially in view of the fact that better error
>   prevention is worth much more than faster compilation, it would seem
>   that the tradeoff made by Ada is certainly the one to be preferred.

The "tradeoff made by ADA?" Do you mean poor code generation versus code that
can be read by non-programmers? Or do you mean the language syntax that
creates nightmares for maintenance? (Does Ada allow you to redefine the
precedence of operators?) Or maybe you mean "language that the government
will use" versus "language that non-government related software companies
will use"?

		Scott MacHaffie