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 |
I worked for a big oil company. They had put a lot of time and effort into doing RPG-II programs on a 'former generation of equipment'. PL/I was the 'new big thing', before C was around. So we wrote an RPG-II to PL/I converter in PL/I. ... It was pretty easy until one feature was found. Basically when the RPG-II tables function was used, we would code it's logic in PL/I by hand. I had to learn RPG-II (and had not long before learned PL/I after doing assembly and FORTRAN in college). Someone elses design, I just coded it. Still it was a good hack. Saved the company lots of $$ by being able to move from older to newer equipment. They eventually saved even more by re-coding the application systems that had used the converted code into native PL/I. On another system, I maintained code that that was originally written in PL/I. It was run through a PL/I to COBOL translator. And was maintained in COBOL. After a few years, we purchased the software and re-coded high use/high maintenance sections back into native PL/I. Faster, cleaner code was the result. Maintaining converted code takes lots of manpower. ... The moral is, IMHO, the best idea for moving from one language to another is to re-analyze the application. Take in any list of deficiencies, and 'must have's and design and wright the new system. ... Code to code conversions are OK, but have a limited lifetime. ... Newly analyzed systems and new coding typically add a significant amount back into the viable lifetime of custom coded applications. ... Just some notions after being in the trenches way to long.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |