Re: "C" AND Ada

[kent@xanth.UUCP (Kent Paul Dolan)]

In article <19093@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
>In article <2537@ames.arpa> eugene@pioneer.UUCP (Eugene Miya N.) writes:
>>In the case of the Space Station (note caps), the word very high is any
>>software developer writing for the Station MUST use Ada.
>
>This raises a question -- are there any C to Ada translation programs.
>We (SDMS Inc.  CCA is just the machine that we use for Vax BSD work) have
>a product that sells into people who sell into DoD.  My opinion of Ada
>is not germane; at some point we are going to have to come to terms with
>Ada and we may have to deal with the prospect of converting to Ada for
>some markets.  I expect that other software vendors are in the same boat.

I'm sure such a translator could be written and may well already have been
written.  Using it would be the highest kind of foolishness, however.

Ada(tm) is not just another way to write C, or FORTRAN, or COBOL.
Ada, by design, embodies the "best informed understanding" of what a
programming language needs to support the wisdom developed by software
engineering theoreticians and practicioners.  Used correctly, it can
provide spectacular benefits.  I sat in on a presentation in about
1984 by a vendor of business software of the typical "20% development
costs, 80% maintenance costs" breed who detailed converting a suite of
programs from Pascal (a rather nice to maintain language itself) to
Ada, and saving 7/8ths of his maintenance costs!  That is a better
than two thirds cost savings over the lifetime of the code.

This is what DOD paid for when they bought Ada, not just a mechanical
translation with the same old maintenance headaches in the new program
as in the old.  I don't think "translated" programs would get a very
friendly reception (I sure hope not); software needs to be rethought,
and rewritten from scratch, fully using the software engineering tools
that Ada provides, to bring Ada's benefits to the user/customer.

Sorry to be so dogmatic about this (can you say "True Believer"?), but
I've been through two mainframe conversions (one federal, one private)
that used mechanical code translation, and it was a mistake, even when
the translation was COBOL 68 to COBOL 74.  The code ends up _less_
maintainable, not more, as the idiot machine butchers the carefully
hand formatted comments, ignores improvements provided in ways to do
things by the new language, and generally just blunders along.

Kent, the man from xanth.