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
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Fri, 1 Aug 2003 08:12:51 -0400
MIME-version: 1.0
Reply-To: Roger Racine <[log in to unmask]>
Content-type: text/plain; format=flowed; charset=us-ascii
From: Roger Racine <[log in to unmask]>
In-Reply-To: <>
Content-transfer-encoding: 7BIT
Parts/Attachments: text/plain (161 lines)
I don't really think the actions of either the contractors or the DoD
constitute either stupidity or malpractice.  Ignorance and lack of
backbone, maybe.  Perhaps they are simply realistic.

The people at the meeting who gave indications that they were sorry to have
to use languages other than Ada were saying (correctly, I think) only that
projects are more productive with Ada.  It is possible (with a lot of
effort) to get defects out of C and C++ code.  My company wrote the
software for the Apollo program, in assembly code.  Our country's strategic
missiles have software written in assembly code.  I firmly believe that
both those systems had (for Apollo) and have (for our missiles) very few
defects.  But the cost of the analysis and testing for both of those
programs were -quite- high.  The same is true for C and C++.  I finished a
C project last year, and am fairly confident in its quality.  But I am also
quite familiar with the weeks of time it took to find each of a number of
bugs that would have either been found by an Ada compiler or given an
exception if we had used Ada.  So the cost of getting to the end quality
would have been lower (which I unsuccessfully had argued 2 years
previously; the sponsor wanted C).

So I don't think anyone at that meeting was stupid.  The people who did the
interviews with prospective employees -might- have been able to convince
them to work on Ada projects if they had better knowledge of the
benefits.  Show hard evidence that the employee would be more productive,
and perhaps they would not have had as many rejections.  So ignorance of
productivity gains could be a problem.

The companies could have held their ground and waited for the willing
employees.  The way it was, it was a negative feedback control loop: the
fewer the projects in Ada, the fewer people wanted to use it.  The fewer
people who wanted to use it, even fewer new projects will use it.  If they
would be firm, it -might- turn around and be a positive control
loop.  Especially now, when there are few jobs and lots of candidates, I
would expect much less resistance among prospective employees.

Roger Racine

At 12:09 PM 7/31/2003, rleif wrote:
>Stupidity is the oldest mental disease! Unfortunately, the software
>profession does not have any means for the determination what constitutes
>malpractice or imposing the appropriate penalties.
>If the DoD followed standard management and/or engineering rules, there
>would now be a postmortem on the functioning of all weapons systems used in
>Iraq II. This would include the reliability of the software and its
>correlation with the programming language used.
>Bob Leif
>Robert C. Leif, Ph.D.
>e-mail [log in to unmask]
>-----Original Message-----
>From: Team Ada: Ada Advocacy Issues (83 & 95) [mailto:[log in to unmask]] On
>Behalf Of Roger Racine
>Sent: Thursday, July 31, 2003 4:54 AM
>To: [log in to unmask]
>Subject: Re: DASIA 2003 excerpts
>Last week there was a meeting of The Open Group's Real-Time & Embedded
>Systems Forum, which works on software standards.  A lot of the work is in
>the area of safety-critical software, and is focusing on Java as a
>language.  The interesting thing from the Ada perspective is that many of
>the people at the forum seemed (at least from the comments I listened to)
>to be unhappy that they were not able to use Ada.  Ada is now banned by
>some parts of the DoD.
>I talked to a couple of people about this, and was told that companies that
>wanted to use Ada were getting rejected by potential employees specifically
>because of the use of Ada.  I asked if that is still occurring, or if it
>was a few years ago when there were many fewer available people, but no one
>knew the answer.  They basically said it was too late.
>There were a couple people who actually did not like Ada, but it was more
>that they had had bad experiences with specific compilers.
>By the way, Ben Brosgol gave a quite good talk on lessons learned using Ada
>for safety-critical applications and did point out that Ada is still alive
>and being used on new projects.  The point I got out of the talk was "The
>Ada community has solved the safety-critical problems.  Why waste time
>fixing the same problems for Java?"  I think others might have gotten a
>different point.  :(
>Roger Racine
>At 12:45 PM 7/29/2003, Colin Paul Gloster wrote:
> >At last month's DAta Systems In Aerospace conference
> >Christophe MORENO of Alcatel Space announced in his "Plug &
> >Play Architecture for On-Board Software
> >Components" presentation that he is using Ada 83. 24 minutes
> >later during Astrium's Matthias Wiegand's "Next Generation
> >Avionics System for Satellite Application" presentation,
> >Matthias Wiegand said "Ada is possible". During the
> >"Software Agents 2: A Minimal Real-Time CORBA ORB for
> >Space" presentation by what Science Systems (Space) had
> >become, it was revealed that the company is working on a
> >minimal realtime CORBA ORB for which Ada 95 support is being
> >developed.
> >
> >CNES's Francois Bossard spoke about a software architectural
> >model in his "Event driven architecture for hard real-time
> >embedded systems" presentation which has been implemented in
> >Ada. An interface for C in middleware was later added.
> >
> >A strange part of the conference ...
> >
> >GMV had a presentation on its "CPFPS: Development of a
> >Safety Critical Hard Real Time Distributed Application for
> >EGNOS". The programmers programmed in C. They coded over
> >120000 lines. They were worried about memory leaks. They
> >found hundreds of memory leaks which had not already been
> >detected in testing. For the project, verification was
> >automated whenever possible, including memory leak analysis.
> >
> >Hundreds of errors were found at unit level. After fixing
> >these, about twenty errors were found at system level.
> >
> >MISRA C was not used because of its restrictiveness, but
> >'99%' of MISRA C was used. The GMV presenter claimed that a
> >lot of erroneous C programs can not be detected by Lint.
> >
> >He had spent about seven years with Ada, so it may have
> >seemed that he would want to have used Ada for EGNOS's
> >CPFPS. However, he complained that Ada compilers he had used
> >or an Ada compiler he had used is buggy. Also the abstract
> >at the conference reveals "A trade off was performed between
> >C and Ada, other languages being discarded very early in the
> >process, and finally C selected. The DoD dropped the Ada
> >mandate for any kind of software in 1998, but reports from
> >the AdaIC state that Ada was not the dominant language for
> >Weapon Systems already in 1994, [..]".
> >
> >Hmm,
> >Colin Paul Gloster
> >
> >P.S. While I am emailing an Ada advocacy list, an excerpt
> >from an email from an email list of the Association of C &
> >C++ Users of July 27th, 2003:
> >
> >"Your argument seems to boil down to the question of what's 'morally' a
> >or non-const method.
> >That's fair enough but I think that C++ has always had a problem here in
> >case. Const methods can so easily modify the logical state of composite
> >objects that I don't see how you can rely on const to tell you that the
> >logical state is left unaffected - at least not at the level that the
> >language can enforce."
>Roger Racine
>Draper Laboratory, MS 31
>555 Technology Sq.
>Cambridge, MA 02139, USA
>617-258-3939 Fax

Roger Racine
Draper Laboratory, MS 31
555 Technology Sq.
Cambridge, MA 02139, USA
617-258-3939 Fax