Re: Ada safety road Was: Which is right ...

[Robert Dewar <robert_dewar@my-deja.com>]

In article <929221844.567.59@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
> Robert Dewar wrote in message <7jsdkf$v3p$1@nnrp1.deja.com>...
> >In article <929128919.557.95@news.remarQ.com>,
> >  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> >> I was talking exactly about such kind of document (may be
more
> >> comprehensive though).
> >
> >I am really not sure how this document could be more
> >comprehensive. Perhaps you miss the point, which is that
> >it is VERY specifically aimed at safety critical programming
> >in Ada, and is not for a moment a general style document.
> >
> >In fact safety-critical programming is a rather specialized
> >area, so although I agree this document is very valuable,
> >I am not quite sure I share your view of its universal
> >applicability!
>

> Please read more carefully other people posts prior to making
> claims that
> someone has missed the point.
> Many people have heard this more than once :-(
> It seems that we have here one person who thinks that he never
> misses the point :-)
> Let's join the club :-)
>
> As a matter of fact I was talking  "about such kind of
document " that I had
> in mind   when I did not know about N359.
> I could not  agree  that writing reliable software is
> specialized area.
> Just contrary I think that this is universal area.

There is a big difference between high integrity software
(yes, most certainly safety critical is a little too
restrictive) and the general notion of reliable software.

All software should be written in a reliable manner, and using
techniques that promote reliability.

The danger of making the jump from high integrity to realiable
with such facility, is that the next thing you know, managers
decide that the kind of restrictions that are suggested in the
HRG document are appropriate for general purpose programming
if "realiability" is important. Since reliability is ALWAYS
important this will mean that we get more of the disease of
arbitrarily forbidding critical Ada constructs under the
illusion that it helps!

I have more than once run into situations where people write
a chunk of a program in C because some nitwit manager has
forbidden the use of (e.g.) unchecked conversion completely.

Validimir, it was you who said you thought the HRG document
could be more comprehensive -- what did you mean?

Remember that the HRG has a very restrictive mandate. As it's
name implies it is in the specific business of looking at issues
related to Annex H, the Safety and Security annex of the
standard. It is not at all the case that the document at hand is
in any sense a general prescription for all Ada programming, and
if people read it with this (mis)understanding, then it is a
pity, because this very valuable (in context) document may end
up resulting in some significant negative effects.

So there's the question Vladimir -- to make your position VERY
clear, explain your criticism of the HRG document, namely that
it is not comprehensive, by giving examples where you think it
is lacking.

My point of view is that this document is an excellent AND
complete summary statement of what is needed for high integrity
programming in Ada.






Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.