TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding: quoted-printable
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Peter Amey <[log in to unmask]>
Date: Tue, 3 Dec 2002 15:17:39 -0000
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Reply-To: Peter Amey <[log in to unmask]>
Parts/Attachments: text/plain (51 lines)
>-----Original Message-----
>From: Clyde Roby [mailto:[log in to unmask]]
>Sent: 03 December 2002 14:33
>To: [log in to unmask]
>Subject: Future of Ada
>Team Ada,
>There seems to be some active consideration by a large
>aerospace/defense contractor about how they transition from Ada to
>other languages (e.g., C, C++).  They currently maintain millions of
>lines of legacy Ada code and they perceive that the supporting
>infrastructure (e.g., skilled labor, tools) is dwindling.
>I'm not aware of any efforts regarding Ada legacy code conversion.
>Indeed, there still seems to be efforts on-going for conversion of
>Jovial legacy code using automated tools.
>What are your thoughts?

My thoughts are that we should continue, energetically, to explain why their migration away from Ada is wrong-headed, based on false premises and likely to be an expensive mistake.  

We have some good evidence that Ada (and SPARK) can reduce cost and raise quality.  On the C130J programme, the error density in C code was an order of magnitude higher than that of the Ada and two orders of magnitude higher than that of SPARK.  This is for code that was already certified by the FAA to DO-178B level A and which had all been produced by skilled practitioners with good tools.  Furthermore, the SPARK code (100 times better remember) cost a quarter of Lockheed's usual cost for Level A.

We should be asking these engineering professionals what overwhelming, unavoidable force is compelling them to accept one to two orders of magnitude higher error rates together with increased costs.  There reasons must be truly impressive to make such a backward step.  

Tool support is a red herring.  Most of the Ada compiler vendors use compiler back ends that are common to other languages.  So we are to believe that Greenhills C++ will be available for ever but Ada is dead? GCC is eternal but GNAT is doomed?  Why don't we ever hear people complaining about moving their legacy Whitesmiths or K&R C to a new platform for which there is only C90 available (I'd say C99, but of course there aren't any C99 compilers)?  This is a common and real problem that they just put up with.

As for skilled people, the perceived shortage is due to the bizarre way our industry confuses skills and products.  The most important quality driver in software systems development is domain expertise.  It is no good having millions of C++ programmers available if you can't trust them to build your flight control system.  If an engineer is safe to be let loose on such a control system, I can teach him SPARK in a week.  If he is not fit to do so then I can't teach him to be a good engineer in a lifetime (even if he is the best C++ hacker in the world).  At Praxis, we solve the skill shortage by recruiting good engineers (even if they don't have that common non seqitur: "10 years experience of the latest fad")  and teaching them the languages we need to use.  We don't allow our engineering judgements to be dictated by what is currently "cool".

What is clear is that if professional engineers keep selecting second best solutions for spurious reasons then they will eventually only have second best solutions to choose from.  They will have been proved right, of course, Ada will have died, but it will be a Pyrrhic victory.  Anyone fancy writing a flight control computer in Visual C# for embedded WinCE?  Thought not.


P.S. We are currently helping a client replace a Jovial system with a brand, spanking new Ada one!

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept 
for the presence of computer viruses.