TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Programming Language Advocacy (83 & 95)" <[log in to unmask]>
X-To: Toshitaka Kumano <[log in to unmask]>
Date: Fri, 9 Jul 2004 20:51:06 +1000
Reply-To: Alan and Carmel Brain <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-2022-jp"
From: Alan and Carmel Brain <[log in to unmask]>
Parts/Attachments: text/plain (93 lines)
It depends on the problem domain.

If your problem is to get the thing done as quickly and cheaply as possible,
with as much unreliability as you can get away with, and quickness-to-market
and most-features-possible (whether useful or not) are critical for success,
then you use one technique.

If you want something which people can bet their lives on, then you use another.

Ada is being marginalised into a niche. Only projects such as aircraft and
spacecraft avionics use it more than they use other languages.

The trouble is, that all the arguments for using C, C++ etc hold even more
for Visual Basic, Visual Basic for Excel etc. There, a new compiler comes
out every few months, there are literally millions of cheap programmers
available, and vast numbers of tools come out every year to try to get around
the languages' basic limitations. This is even more true for assembler:
every time a new CPU comes out, a new assembler is made for it, and soon
thereafter, tools for assembler code-generation in vast profusion, often
C or C++ compilers.

But this is preaching to the converted, and of limited use to the original poster.

Hopefully what I have to say below may help.

> To persuade manager with technical superiority of Ada is of no use here,
> because they understand that to some extent, and they simply concern
> about shortage or soaring price of tools in future.

The first non-Japanese payload to be carried on board a NASDA rocket was the
Australian 'Fedsat' satellite.

The satellite bus was programmed entirely in Ada-95.

The CPU was the ESA-designed ERC-32.
The RTOS was RTEMS, originally designed in Ada, but later ported to C. This
is freeware, it cost us nothing.
The application was programmed using the GNAT 1.13p compiler. Free, it cost us
nothing.
The tool we used to simulate the ERC-32 was written in Ada, and we used the
freeware version, which cost us nothing.

The FedSat satellite had experiments on board including a Magenetometer, a GPS
system, a communications payload for mail-forwarding to ocean buoys, a
star camera, and a FPGA (Field Programmable Gate Array) experiment. In
addition, the Attitude Control System was space-qualified by FedSat,
Architecturally, it too was basically another experimental payload

All of these payloads, and the satellite system itself, are seperately
re-programmable via telecommand from the ground. Since launch, several
have been re-programmed, and FedSat has demonstrated for the first detection
and self-repair of radiation damage using FPGAs.

Fedsat is almost certainly the most complex satellite of its size ever
launched. Some CPUs used IEEE-format floating point representation, some
used 1750 format. The Mass memory used a different endianism from the rest
of the satellite, and due to financial constraints, wasn't fully populated:
thus ABCDEF in addresses 0-5 would be stored as BAxxDCxxFExx in addresses 0-11,
with bank-switching between pages. Coping with this was difficult in Ada-95,
but doing so in C or C++, within the very strict and tight time performance
constraints, and also preventing starvation or lockup with multiple
concurrent processes attempting to use this common resource... would have been
impossible given the budget of time and money, especially for a high-rad
environment with soft-failures certain.

The total software budget for the satellite (though not the payloads) was
on the order of $300,000 USD, and the software team was an average size of 2,
with a peak of 3 and a trough of 1. During the final 6 months before launch,
the sole programmer involved was a new graduate (who had never used Ada outside
one semester at University before starting the project 12 months previously).

If you wish to get more details about the project, feel free to contact me.
I headed the Spaceflight Software Development Team, and wrote about 1/3 of
the code on board the bus.

Given these metrics - zero cost compiler, zero cost emulation tools, and
being able to train a beginner Ada programmer to become an outstanding one
within 12 months, it is very difficult to see any objection to the use
of Ada from a maintainability viewpoint. Especially since the last update
to the satellite's software was performed by another Ada beginner, one
who wasn't on the original team (good documentation really helps with
any language, but with Ada it makes maintenance by beginners normal, cheap
and reliable)

It may not be true when writing the next video game, nor the next
'killer app' financial spreadsheet, and certainly not when doing GUI
prototyping, but when you have to have reliability and re-useability,
Better
Cheaper
Faster
With Ada-95 it's 'Pick any three'. The proof is in orbit, put up
there by a Japanese rocket.

ATOM RSS1 RSS2