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
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
