Not by choice but rather out of desperation and necessity to continue to run the mission critical code, mostly in banking, finance, and it is also occasionally encountered in government services albeit its presence has greatly diminished in the last decade or so. Young developers have no interest in learning COBOL, and the old developers have alredy died several times, have been dug out of their graves several times and brought back to the frontlines, and there are no more of those to be had. So the mission critical code continues to run on the constantly upgraded mainframe hardware, sometimes having not been changed in a few decades.
Oddly enough, despite a few large scale attempts to come up with automated COBOL -> whatever language migration / translation tools, they seem to have been largely fruitless. I think it was IBM that hired a bunch of hardcore academics in mid-2000's (?) to design and implement a COBOL to Java translator in Standard ML, and they even managed to produce something working. Unfortunately, then history becomes murky and trails off, and the eventual fate of that creation is an enigma of sorts. And, then, earlier versions of Java (before Java 8 anyway) were a horror to behold and would probably require a Java < 8 into Java >= 8 translator, so…
I'd actually love to work with COBOL professionally, my problem is that COBOL jobs still pay a substantially low amount of money compared to jobs using modern stacks.
For something so "critical" you'd think the base salaries would start at $250k/year; but I guess we aren't at that level of desperation yet.
Out of curiosity what about COBOL appeals to you? My first job out of college was working with RPG on an AS/400 (so I'd consider it at least a cousin) and the experience was awful.
Basically wanting to work with a true legacy system, colloquially I feel like
legacy" typically means "abandoned php/java8/c#" project. COBOL projects are older than me!
I think it would really help me grow as an engineer to understand how these systems are maintained, how they are tested, and how they are updated; what better way than something several decades old?
I feel like this is hard to find in the modern era, especially post 2010 onward.
Ah, interesting. I will admit I learned a great deal in the 2 years, though not all of that was the things you said. For me it was we had a lot of different codebases because each client had their own needs (beyond everyone who used our payroll system including printing checks, but that system rarely needed maintenance) so I had to learn to quickly read and understand a codebase to be able to make changes w/o spending days/weeks getting up to speed.
Interesting reading your comment as well! I honestly don't know what I would expect to learn just writing would I think would happen. :D
Thinking about it more, I don't think I've met single person that ever touched a COBOL code base throughout my career (talking from ICs up to VPs here). It seems the "oldest" was always some early Java project from early 2000s.
Because at $250k/yr they'd have no trouble attracting engineers willing to learn COBOL. There isn't a current "emergency" a la Y2K to spike the demand of experienced COBOL programmers; they have time to hire anyone with a CS background and let them learn the language on-the-job so they can do low-priority legacy maintenance.
> […] and let them learn the language on-the-job so they can do low-priority legacy maintenance.
And that is a problem frequently faced with fresh graduates and young developers (no disrespect to them) whose common reaction to legacy programming languages and platforms is best characterised as «ew, this is gross». Even a heftier salary package does not do the job – they just don't want to learn legacy technologies.
As a personal anecdote, it is the situation I encountered with a few young devs (3-4 years of the industry experience) in my team whom the management had entrusted to learn and support a 4GL platform that they borderline flatly refused to learn and left their employer shortly afterwards to code in React and other NodeJs frameworks. Which is regretful as the 4GL language in question was a pretty modern and good design and could have been learned to get a glimpse into good design and coding practices, the intricacies of the complex transaction processing etc. All of which could have been reused pretty much anywhere outside 4GL. In my view, it was a sorely missed opportunity.
The '08 recession forced me into a job maintaining an old Ada system when I was a young developer. Toward the end of that experience I was put on a project that involved modernizing and updating said system by porting it from SPARC/Solaris to x86/RedHat. I also had to learn to read MATLAB because most of the new modules involved translating the work of scientists into Ada code.
A good learning experience, at least. I've long since moved on to more "modern" technologies.
Not by choice but rather out of desperation and necessity to continue to run the mission critical code, mostly in banking, finance, and it is also occasionally encountered in government services albeit its presence has greatly diminished in the last decade or so. Young developers have no interest in learning COBOL, and the old developers have alredy died several times, have been dug out of their graves several times and brought back to the frontlines, and there are no more of those to be had. So the mission critical code continues to run on the constantly upgraded mainframe hardware, sometimes having not been changed in a few decades.
Oddly enough, despite a few large scale attempts to come up with automated COBOL -> whatever language migration / translation tools, they seem to have been largely fruitless. I think it was IBM that hired a bunch of hardcore academics in mid-2000's (?) to design and implement a COBOL to Java translator in Standard ML, and they even managed to produce something working. Unfortunately, then history becomes murky and trails off, and the eventual fate of that creation is an enigma of sorts. And, then, earlier versions of Java (before Java 8 anyway) were a horror to behold and would probably require a Java < 8 into Java >= 8 translator, so…