[Discuss] FORTRAN -> ???

[bill at horne.net (Bill Horne)]

On 1/22/2012 2:02 PM, Daniel C. wrote:
> I was talking to an ex-co-worker last night and he said that he's
> having trouble finding a programmer to maintain their FORTRAN
> codebase.  The conversation got me thinking - there must be a way to
> automatically change older languages (FORTRAN, etc.) into something
> newer.  At the very least you should be able to compile the program
> into machine code, then use a decompiler to bring it back into C.
> That really shouldn't be necessary though - you should be able to have
> a compiler move FORTRAN straight into the language of your choice.
>
> Does anyone know of an automated tool to do this?  I checked Google
> and a few things came up but nothing that looked particularly helpful.
>
>

Dan,

I'm assuming that the tools available to convert FORTRAN to C have 
gotten better since the last time I was exposed to them, but a 
cautionary note is probably still in order.

I was witness to an overly-ambitious project during my time as a Systems 
Analyst in a previous life, and that project spelled the end of a career 
for an up-and-coming manager who was well regarded and respected in the 
company. The man made the mistake of believing forward-looking 
projections made by salesmen for a vendor which promised that 
software-aided-design tools would be able to translate existing COBOL 
and FORTRAN code into C.  A Systems Analyst I knew there, who was 
involved with the project, described the product they were selling as "A 
Gold-plated Cadillac, with Gold-plated hubcaps and Gold-plated tires, 
but without a steering wheel. But (he added) they tell you that when 
they have figured out the steering wheel, /that/ would be Gold-plated, 
too".

There were a number of complicating factors, all of which contributed to 
the disaster, and I mention some of them here to make it clear that 
code-conversion tools /can/ be used if you're careful not to make 
overly-optimistic assumptions about their capabilities, and to allow for 
lots of time to re-integrate the "new" programs into the existing 
application or system.

 1. The project was intended to completely replace the existing "big
    iron" billing system, which had been built up over perhaps twenty
    years, with a leaner, more-focused, and markedly more efficient
    system written in C.   C was chosen, as far as I knew, because a
    recently-hired CIO had decided to make it the "official" language
    for all future development.
 2. The project started out with the idea that it was possible to
    recover the business rules of the old software and implement them
    into C code by using CAD software to convert "old" code to "new"
    code. In other words, it was a classic "Deus ex machina" error,
    where the staff assumed that the "Gold-plated Cadillac" they had
    purchased would be able to discern what the C code would be, based
    on what it found inside COBOL and FORTRAN programs. Those programs
    had been written by company-trained programmers who had, based on
    their knowledge of the company and its operations, never bothered to
    include logical cases that they assumed, from experience outside the
    billing system, could never occur.
 3. The company, unwilling to endure the high cost of retraining
    unionized employees, had decided that the "new" system would be a
    drop-in replacement for the old, with identical interfaces and
    procedures.


Suffice to say that it all collapsed after about a year, and the project 
manager - who had, as I wrote, been a rising star in the company - was 
fired. The moral of the story, as far as I can tell, is that it's not 
usually a good idea to convert "old" code to "new" languages, since the 
"old" code will most likely include decision trees and options that 
reflect a business model which is  either no longer productive or simply 
not worth trying to reconstruct.

In general terms, when I am asked about systems or applications written 
in FORTRAN, or any third-generation language, I recommend replacing the 
3GL application with a current commercial package that will accomplish 
most of the same functions, and that the owner plan for a substantial 
retraining and retooling effort in the process.

FWIW. YMMV.

Bill "God is real unless declared Integer" Horne

-- 
Bill Horne
339-364-8487