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.