This is right up my alley; I work for a large financial firm doing COBOL work right now.<p>The language itself isn't that bad. There are a lot of quirks given how old it is (variable names being limited in size, file name being only 8 characters long, file-based scope, etc), but once you learn them it's really not that bad.<p>The best thing about the language is how it enforces a particular programming style. You have to define ALL variable and external data sources before you're able to use them. And when you get to the meat-and-potatoes of the program, a certain style is primarily used: open external resources (files, DB2 tables), check for IO errors, process the data, close the resources. Makes it easy to grok what's going on within a program (even if that program is older than you are).<p>The biggest challenge that I see for new COBOL programmers is learning all of the tools you'll use for your job. On the IBM zSeries Mainframe that we use, there are a TON of tools that we use to monitor our batch/CICS online programs. But that, like everything else, will take practice.
Assuming I wanted to pick up COBOL and land a contract gig, what else do I need to know? A language is syntax but also libraries, patterns, and ecosystem. For instance it's hard to do Rails without knowing Git, Bash, Linux, SQL, Javascript, CSS, RSpec, Capistrano, Devise, MVC, etc. Do COBOL apps typically talk to relational databases, or is everything stored in fixed-width flat files? Do COBOL programmers use git? Am I going to need to keep an AS/400 running in my garage?
Counter-argument: Old apps, of the sort that are written in COBOL, are often ones that there are good reasons to replace anyway.<p>The reason they tend to still exist, where they do still exist, is that businesses don't want to dedicate the budget to the replacement. But that also means that they don't want to dedicate a huge budget to maintenance, either. If COBOL actually gets rare enough that COBOL devs start getting high-end wages, it makes the "replace this thing" option look that much more appealing, which pretty much puts a ceiling on the demand for COBOL devs.<p>If you are a purely mercenary developer, don't learn COBOL, because it's not where the money is.
I studied at the University of Wisconsin-Platteville and was forced to take a COBOL class. Anyone in the Computer Information Systems emphasis was required to take several COBOL-centric classes. A few classmates went on to write COBOL on the job and they were definitely getting higher offers than the rest of us looking for "cool" jobs.<p>On the other hand, the only COBOL shop in town pays meager wages and is considered to be the place where your career goes to ddie.
My mom programmed COBOL back in the early 70s while she was doing the hippie thing back out in Berkeley. After that she learned basic and taught me that on my Apple IIc. All as a six week college dropout.<p>I always have wondered what it would've been like if she had stuck with that instead of going off to live in the woods of New Hampshire.
I had no problem with Cobol back in the day, it was a fairly easy language to use once you got used to it. The main problem I have seen is the utter crap way its programmers were treated after the whole Y2K thing was over with. Why would anyone want to walk into a job like that when they can learn Rails and be a 'Rockstar' or any other web-based offering and at least be treated like a valuable commodity?
We have quite a bit of COBOL and are seeing a similar challenge recruiting and maintaining COBOL developers. We're in talks to partner with a local workforce education center to put together some training for potential or existing employees who might be willing to transition into a COBOL role.<p>I'm imagining that these folks would be non-programmers who are identified as having good reasoning and structural thinking, and who could receive a pay bump by moving into a development position. I don't expect that existing developers would want to move away from their current skillset trajectory and I think that route is probably not a fruitful one to pursue.<p>It remains to be seen if this will be a successful endeavor.
The perception is that the COBOL jobs don't pay as well as Ruby, Node, etc.<p>It this is not the case, then the recruiters are doing a bad job winning the hearts and minds of job seekers and those try to follow hiring trends.
Well, not as much a return as a stubborn refusal to be phased out, resulting in a trickle of new development and job offerings.<p>Fortran is also alive and kicking, also in narrow but well-entrenched niches. Modern Fortran became a nicer language, though, then e.g. Fortran IV or 77.<p>Bigger fun will begin when C will be universally seen as a legacy language, inexpressive, full of pitfalls and undefined behaviors, etc, but huge amounts of important C code will have to be maintained without a chance of rewriting it in a nicer language in sight.
I have to mention J. Wayne Spence's <i>Cobol for the 80's</i> <a href="http://www.worldcat.org/title/cobol-for-the-80s/oclc/7975830" rel="nofollow">http://www.worldcat.org/title/cobol-for-the-80s/oclc/7975830</a> again. Oh how I laughed when I saw it on a library shelf, back in 1995 or so...
This begs the question. Why haven’t ecosystems that rely on Cobol been extinct or at the very least moved on with times? I can understand that some of those are mission critical systems where you just don’t mess around but there are some very stable frameworks out there that are also modern and have first class enterprise support behind them.
I don't think it's going to be an issue of finding people to take over COBOL systems, companies that are interested are simply going to round up students and give them part time jobs where they can learn COBOL and earn some side cash with a promise of a good job when they get out of college.
TL;DR for the comments:<p>Idealist: Why don't enterprises move to modern and stable systems?<p>Pragamatist: Literally billions of small programs/processes are written in this and they work reliably.
not sure about cobol, but most of the serious supercomputing simulations are written in fortran, and in my opinion, lisp is the most beautiful language ever written in computing history.