2 ms·
I've always wondered about the following approach for old apex predators like COBOL and FORTRAN, it follows what .NET does. The idea is to take current COBOL a
by filereaper 9y ago
I've always wondered about the following approach for old apex predators like COBOL and FORTRAN, it follows what .NET does.
The idea is to take current COBOL and FORTRAN code and compile it down to IL similar to .NET's CIL, in the .NET world once code is brought down to CIL it can be read back in VB.NET, C#, C++.NET
Essentially bring it down to some sort of lossless IL to convert to another language. It should be possible to do this given we have the source code. In certain cases where source code doesn't match the binary (happens over years due to monkey patching the binaries etc...) then we'll have to take an approach a few folks at IBM are talking with recompilation and reoptimization of existing old binaries for COBOL. [1]
Don't throw away that debugged and battle-hardened code, change the IL and the final compile target, if possible re-interpret the IL into a newer language if its not lossy.
[1]http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&appname=gpateam&supplier=897&letternum=ENUS215-407&pdf=yes http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&s...
- mschaef 9y agoMicroFocus has done COBOL for .Net for years... https://www.microfocus.com/products/visual-cobol/ https://www.microfocus.com/products/visual-cobol/ "Compile COBOL applications directly to Microsoft intermediate language for deployment within Microsoft .NET... Compile COBOL applications to Java byte code for deployment within the Java Virtual Machine" I've actually seen this idea suggested, at least as part of a bake-off between design ideas. There's a certain amount of sense to it.