Re: Customer balks at Ada -- any hope?

["Samuel T. Harris" <samuel_t_harris@Raytheon.com>]

Ken Garlington wrote:
> 
> However, feel free to choose your own path:
> 
> (a) I will limit myself to the controllers with native Ada support
> (b) I will target (and maintain) GNAT for any controller selected
> (c) I will assume that any selected controller has a C compiler, and will
> use an Ada-to-C translator
> 

Actually, the path (as you describe above) to which I was
alluding was to initially go with (a) with the knowledge
that I can always switch to (c) if I absolutely need to.
Switching to (c) should have minimal impact on my existing
Ada code (which is a primary concern in such cases).

My initial response concerning Ada-to-C translators was
in the context of future changes to the architecture
involving components with C but no Ada support!

Knowing I can support Ada where ever C is supported
mitigates that particular risk. Of course, path
(b) can also be kept in mind to mitigate that same
risk but I believe that (c) will nearly always be
much cheaper than (b).

Also, the pun of you letter scheme is not lost on me :)

To expand further on the notion, it is true that
Averstar produces an Ada-to-C translator. Introducing
an "new" C compiler to that mix does involve issues
of who will perform the integration work and who
will warrant the result. Please note that ICC also
produces Ada compilers which produce C. The difference
is that they do all the integration work making
the use of C as an intermediary nearly invisible
to the user organization! Of course that work comes
at some cost which. So all the elements of a make/buy
decision are available is path (c) becomes necessary.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"