Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |