TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Content-Transfer-Encoding:
7bit
Sender:
"Team Ada: Ada Programming Language Advocacy (83 & 95)" <[log in to unmask]>
Subject:
From:
Alan and Carmel Brain <[log in to unmask]>
Date:
Sat, 10 Jul 2004 00:07:58 +1000
Content-Type:
text/plain; charset="iso-2022-jp"
MIME-Version:
1.0
Reply-To:
Alan and Carmel Brain <[log in to unmask]>
Parts/Attachments:
text/plain (96 lines)
Pardon if this is a repeat, I didn't get confirmation of receipt from
the list server.

> 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