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.
COBOL is solved problem; there is no need for a new COBOL compiler.
I'll never understand this attitude. Though I suspect it's why so much modern software ends up being hundreds of megabytes of libraries uncomfortably glued together.
After all, if we didn't reinvent the wheel, my bicycle would weigh 800lbs.
Not totally unrelated: It's essential for the long-term health of any programming language to have multiple, compatible, implementations. I'm sure you can think of a few programming languages that died because the maintainers of the only implementation gave up on it. I
There may well be people asking whether there is a COBOL compiler on x86 they can _buy_. Some people and organizations do not understand FOSS. Or they want to pay money so they can sue later if things do not work. (Good luck with that...)
Or they want to pay money so they can sue later if things do not work. (Good luck with that...)
Or just for passing the buck reasons. "We used IBM, how could that possibly go wrong?" No need to justify your decision to choose the 800 ton gorilla, like you would with something that cost $0.
Indeed. There is also the fact that large organizations waste tons of money on stupid stuff already. The cost of paying for a compiler will be negligible in comparison.
On an unrelated note, since I have seen an IBM big data team completely fail their project in a big bank (by abysmal incompetence...) I do not believe that IBM gets the job done anymore. Before that I thought they were expensive, but could really get things done.
I think it is so IBM can keep its business partnerships. Companies are no longer buying mainframes, and big iron. While a modern mainframe is an amazing computer to work on, and handles heavy load like a real champ. It is extremely difficult to justify that performance for its price, then factoring in today's business need to fail-over and redundancy it gets way more expensive very fast.
They are a still a lot of COBOL code out there running things, but IBM Customers are looking at the expense on keeping t
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.
Re: (Score:2)
COBOL is solved problem; there is no need for a new COBOL compiler.
I'll never understand this attitude. Though I suspect it's why so much modern software ends up being hundreds of megabytes of libraries uncomfortably glued together.
After all, if we didn't reinvent the wheel, my bicycle would weigh 800lbs.
Not totally unrelated: It's essential for the long-term health of any programming language to have multiple, compatible, implementations. I'm sure you can think of a few programming languages that died because the maintainers of the only implementation gave up on it. I
Re: (Score:2)
There may well be people asking whether there is a COBOL compiler on x86 they can _buy_. Some people and organizations do not understand FOSS. Or they want to pay money so they can sue later if things do not work. (Good luck with that...)
Re: (Score:2)
Or they want to pay money so they can sue later if things do not work. (Good luck with that...)
Or just for passing the buck reasons. "We used IBM, how could that possibly go wrong?" No need to justify your decision to choose the 800 ton gorilla, like you would with something that cost $0.
Re: (Score:2)
Indeed. There is also the fact that large organizations waste tons of money on stupid stuff already. The cost of paying for a compiler will be negligible in comparison.
On an unrelated note, since I have seen an IBM big data team completely fail their project in a big bank (by abysmal incompetence...) I do not believe that IBM gets the job done anymore. Before that I thought they were expensive, but could really get things done.
Re: (Score:2)
I think it is so IBM can keep its business partnerships.
Companies are no longer buying mainframes, and big iron. While a modern mainframe is an amazing computer to work on, and handles heavy load like a real champ. It is extremely difficult to justify that performance for its price, then factoring in today's business need to fail-over and redundancy it gets way more expensive very fast.
They are a still a lot of COBOL code out there running things, but IBM Customers are looking at the expense on keeping t