From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,55ae3803eb91d6ca
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe13.iad.POSTED!7564ea0f!not-for-mail
From: "Michael" <fvit@shaw.ca>
Newsgroups: comp.lang.ada
References: <q9ntl.33022$l71.13235@newsfe23.iad>
 <C5DC2FAE.10E8E6%yaldnif.w@blueyonder.co.uk>
Subject: Re: Ada UK conference: SPARK safety: is no delivery better than 1
 defect?
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
Message-ID: <zsMtl.48994$Tp5.224@newsfe13.iad>
NNTP-Posting-Host: 174.6.150.104
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: newsfe13.iad 1236767647 174.6.150.104 (Wed, 11 Mar 2009 10:34:07 UTC)
NNTP-Posting-Date: Wed, 11 Mar 2009 10:34:07 UTC
Date: Wed, 11 Mar 2009 03:34:00 -0700
Xref: g2news2.google.com comp.lang.ada:5003
Date: 2009-03-11T03:34:00-07:00
List-Id: <comp.lang.ada>

Hi all,



Thank you for the question Bill.



iFACTS deficiencies and delays are not due to Ada, (the software engineering 
language), but more likely from the SPARK constraints and limitations.

SPARK is made from a subset of Ada and use specific annotations (e.g.: data 
flow or pre and post conditions assertions) to establish a mathematical 
proof of the code correctness.

http://www.adacore.com/wp-content/uploads/2008/10/11_safe_secure_ada_2005_certified_safe_with_spark.pdf



Within large projects, when using C/C++ it becomes increasingly difficult to 
clearly separate design concerns that are scattered into classes.

("The high-integrity C++ coding standard manual" won't help that much 
http://www.literateprogramming.com/CppHighIntegrity.pdf)



Within large projects, when using SPARK it becomes increasingly difficult to 
focus on establishing abstract proof of correctness without compromising 
testing effectiveness.

("Is Proof More Cost Effective than Testing?" won't help either

http://www.praxis-his.com/pdfs/cost_effective_proof.pdf)



Working on too strong abstractions will not left much tools and utilities 
for the operational problems' emulation and testing. Within a proof of 
correctness context, verification and validation procedures might more 
likely be concerned about monitoring divergences than ensuring 
specifications' compliances.



At the opposite Ada is a powerful engineering tool which allows engineers to 
know what they are doing.  And when complexity is increasing, doing it right 
and doing the right think is mostly a consequence of experiences and of a 
mature software engineering process.



The next Ada UK Conference is an opportunity for Praxis to clarifying the 
SPARK capabilities (Tookeneer) and limitations (iFACTS).

http://www.ada-uk-conference.co.uk/programme.html



Cheers



Michael,

Vancouver, BC



CC: to Rod Chapman and Janet Barnes



>
> Do you have any evidence that iFACTS problems are due to the Ada language?
>
> -- 
> Bill Findlay