There is already GnuCOBOL [sourceforge.net] which translates COBOL into standard C (which is then compiled), is free, passes all the NIST COBOL 85 test suite tests, is translated into a bunch of languages, and is multiplatform.
COBOL is solved problem; there is no need for a new COBOL compiler.
I would think it may even be more complex than that? More like python compilers. I know there are many different versus of COBOL and there might be some limitations to GnuCOBOL that do not really work for the IBM shops that still want to develop COBOL on Linux.
Yeah. It's not as if Microsoft invented vendor lock-in. It was IBM. They were masters of it before Microsoft even existed. Without a doubt (ok, maybe some doubt - I really have never touched COBOL), IBM has COBOL/Blue that adds a few non-standard features.
The only person who always got his work done by Friday was Robinson Crusoe.
But why? (Score:2, Interesting)
There is already GnuCOBOL [sourceforge.net] which translates COBOL into standard C (which is then compiled), is free, passes all the NIST COBOL 85 test suite tests, is translated into a bunch of languages, and is multiplatform.
COBOL is solved problem; there is no need for a new COBOL compiler.
Re:But why? (Score:5, Insightful)
COBOL is solved problem; there is no need for a new COBOL compiler.
That's like saying GCC compiles C so nobody else should make a C compiler.
Re: (Score:2)
I would think it may even be more complex than that? More like python compilers. I know there are many different versus of COBOL and there might be some limitations to GnuCOBOL that do not really work for the IBM shops that still want to develop COBOL on Linux.
Re: (Score:2)
Yeah. It's not as if Microsoft invented vendor lock-in. It was IBM. They were masters of it before Microsoft even existed. Without a doubt (ok, maybe some doubt - I really have never touched COBOL), IBM has COBOL/Blue that adds a few non-standard features.