Yes, the World Still Needs COBOL Programmers(insights.dice.com)
insights.dice.com
Yes, the World Still Needs COBOL Programmers
http://insights.dice.com/2015/12/28/turning-legacy-computing-skills-into-a-job/
2 comments
I code in COBOL. I don't like it that people think it's dead or legacy because often times it isn't and that mindset keeps people from caring about security or using current best practices in COBOL code. Very important things still run on it and new code to run important things is being written in it.
There are a ton of systems that people think are dead or legacy like OpenVMS (what I love and work on) or IBM Mainframes are still current and in use and new installations are going up, and the legacy mindset hinders security best practices and doing new and interesting shit on these systems.
> I don't like it that people think it's dead or legacy because often times it isn't and that mindset keeps people from caring about security or using current best practices in COBOL code.
The only reason COBOL isn't dead is because it is legacy (or, rather, because there is mountains of -- often undocumented, untested, and with requirements and domain knowledge largely lost and buried in the code -- legacy code written in it.)
And that code didn't have security or best practices (including things like loosely-coupled components with well-defined purposes) kept in mind when it was first written, which makes updating it in a manner which respects security and best practices difficult, at best.
The new code being written in COBOL is largely extensions and updates to existing legacy systems.
No doubt there are some exceptions, but they are a small fraction of what is going on with COBOL, which is itself a shrinking niche in programming overall.
The only reason COBOL isn't dead is because it is legacy (or, rather, because there is mountains of -- often undocumented, untested, and with requirements and domain knowledge largely lost and buried in the code -- legacy code written in it.)
And that code didn't have security or best practices (including things like loosely-coupled components with well-defined purposes) kept in mind when it was first written, which makes updating it in a manner which respects security and best practices difficult, at best.
The new code being written in COBOL is largely extensions and updates to existing legacy systems.
No doubt there are some exceptions, but they are a small fraction of what is going on with COBOL, which is itself a shrinking niche in programming overall.
> COBOL programming language is no longer taught in schools
I took a COBOL course just two years ago in a Texas Public University. It was considered the 'I didn't get any offers anywhere else' or 'I am too lazy to apply' if you were picked up by IBM as a COBOL engineer. I was trying to pull up the online syllabus. Seems like they have finally gotten rid of that course (or maybe the professor who taught it finally passed away).
As annoying as COBOL was, it was unique and interesting in the way it handled IO processing. From what I understood from talking with those who had gone the COBOl engineer route from my school, was that it was never quite learning COBOL, but rather all the jank years of programmers added into the codebase. COBOL is annoying, but when you have the equivalent of jank similar to badly designed #define 's all over the place that makes you want to thrash out at everything and anything when you realize what is happening ... that is, from what I have been told, a major reason COBOL sucks.
It wasn't my cup of tea, thus I didn't pursue it, but to fellow classmates, they quite enjoyed it as one would when you program in C. It had a certain elegance to it.
I took a COBOL course just two years ago in a Texas Public University. It was considered the 'I didn't get any offers anywhere else' or 'I am too lazy to apply' if you were picked up by IBM as a COBOL engineer. I was trying to pull up the online syllabus. Seems like they have finally gotten rid of that course (or maybe the professor who taught it finally passed away).
As annoying as COBOL was, it was unique and interesting in the way it handled IO processing. From what I understood from talking with those who had gone the COBOl engineer route from my school, was that it was never quite learning COBOL, but rather all the jank years of programmers added into the codebase. COBOL is annoying, but when you have the equivalent of jank similar to badly designed #define 's all over the place that makes you want to thrash out at everything and anything when you realize what is happening ... that is, from what I have been told, a major reason COBOL sucks.
It wasn't my cup of tea, thus I didn't pursue it, but to fellow classmates, they quite enjoyed it as one would when you program in C. It had a certain elegance to it.