Life cycle costs for FORTRAN+Ada vs. Ada

Life cycle costs for FORTRAN+Ada vs. Ada

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!aero.org!jordan]

Omnes,

I need some references or a summary of findings which address the
life cycle costs of choosing a hybrid (FORTRAN+Ada) vs.
an all Ada effort in scientific applications. 

Here's a bit of background:

A Contractor wants to use FORTRAN to develop some Scientific software.
These scientists (not SEs) are well versed in FORTRAN.  The software
they write will transition to operational software eventually.  That
software is mandated in Ada.  I don't know amount of FORTRAN code
that has to be developed (1K, 10K, 100K SLOC?).

Is it "reasonable" to:

[1] Develop in FORTRAN and "migrate" to Ada?
    o Is conversion/translation of the developed FORTRAN to Ada viable?
    o Or is it better to have a trained Ada programmer to reimplement
      from "language independent" algorithmic descriptions of working
      code?

[2] Or, Require the untrained to develop in Ada from the start? 
    o Take an initial productivity hit an train scientists in Ada?
    o And/Or have a knowledgable Ada programmer(s), who might be
      unfamiliar with the applications area,  work closely with
      the scientists, monitoring what's going on to guarantee "good"
      Ada?

I'd appreciate any lessons learned from practical experience.  I
want to know what works, not what "might" work (I can speculate, too).

What kind of "resistance" can be expected?  Is there any merit to the
counter that "Ada is not a numerical" language?  (I've done no
number crunching in Ada).

Thanks in advance,

--Larry %)

Re: Life cycle costs for FORTRAN+Ada vs. Ada

[Gregory Aharonian]

    There are some problems migrating from Fortran to Ada for scientific
software.  The first is that Fortran allows you to do things with arrays
that is impossible to recreate very well in any other language.  With
Fortran, you cuold pass parts of any dimensional array to a subroutines,
which can look at it like an array of an arbitrary dimensions.  While
this has been put to great use in Fortran (BLAS,LINPACK,LAPACK), it requires
a complete rewrite for strongly typed languages.
     Second, most Fortran science applications use complex arithmetic, whose
implementation in Fortran compilers has been optimized and verified to death.
In Ada (as well as C++) you have to create a complex type and implement all
of the complex libraries yourself, which is not a numericall trivial thing to
do.  I think that there are a few such libraries being offered, but not to
the degree of quality that Ada allows.

     Above 40,000 lines of code, I would suggest that you choose a language
and use it from the outset.  Conversion tools will provide little economic
advantage for second stage translation (and more than likely the guys who
wrote the stuff will not be very excited about translating it to Ada, and
I would not suggest letting anyone else translate their code).

     Actually, teaching a good subset science-version of Ada probably will
not be that difficult, or unpleasant to the scientists, especially if you
turn off dependency-recompiles, which is more aggravating than learning a
new language.

     You might want to contact some of the DoD scientists with major 
Fortran codes (like the Lowtran guys) and ask them why they haven't
converted to Ada (as they still have the freedom to choose).

Greg Aharonian
Source Translation & Optimization

Re: Life cycle costs for FORTRAN+Ada vs. Ada

[Bob Geiger]

In article <1992Apr4.190401.22260@aero.org> jordan@aero.org (Larry M. Jordan) w
rites:

>Is it "reasonable" to:
>
>[1] Develop in FORTRAN and "migrate" to Ada?
>    o Is conversion/translation of the developed FORTRAN to Ada viable?
>    o Or is it better to have a trained Ada programmer to reimplement
>      from "language independent" algorithmic descriptions of working
>      code?

This first option of conversion from Fortran to Ada is the only
one I strongly advise against. This conversion, whether automated
or manual, is likely to yield "Adatran" (Fortran-like Ada) - with
inherently poor maintainability, understandability, portability
(and several other well-known "-bilities"). I have seen this happen
and it's not a pretty sight. Avoid it if possible.
The second will work, and seems most useful if you need to deliver
a design document that describes these algorithms. If you're just
going to use them to implement in Ada, then why waste time expressing
the algorithm in a language independent way?

>[2] Or, Require the untrained to develop in Ada from the start? 
>    o Take an initial productivity hit an train scientists in Ada?
>    o And/Or have a knowledgable Ada programmer(s), who might be
>      unfamiliar with the applications area,  work closely with
>      the scientists, monitoring what's going on to guarantee "good"
>      Ada?

I prefer the second option here. Put together the heads of the
Ada expert(s) and the scientists. I have found that a little
guidance can help speed the learning curve for Ada rookies. The
reason for this is not to help teach the nuts and bolts of the
language - anyone who knows Fortran can write with a similar
style in Ada. The trick is to grasp the new capabilities of
information hiding, abstraction, and object-orientedness (or at
least object-basedness :-) ).

Hope this helps,

Bob

===========================================================================
| Bob Geiger (rjg@rational.com)        Rational                           |
| Technical Consultant                 3320 Scott Blvd.                   |
| (408) 496-3743                       Santa Clara, CA 95054-3197         |
===========================================================================
--
===========================================================================
| Bob Geiger (rjg@rational.com)        Rational                           |
| Technical Consultant                 3320 Scott Blvd.                   |
| (408) 496-3743                       Santa Clara, CA 95054-3197         |