Does learning COBOL still make sense?
I don't think so, unless you are already in the niche market where COBOL is still maintained.
Nooo, of course not. COBOL is a dead language, after all. Or is it?
The problem with that view is that programmers at sites like this one usually work with high tech, fast-running (and equally fast burning-out) companies. For them COBOL is a dead language - it is nowhere to be seen. Has not been for some time now, 'tis true.
But COBOL was not meant for them. There is more to the software industry than this. Computers were not invented for people with some irrational need for upgrading and replacing old with new all the time. They were made for business purposes.
You want to see COBOL? Go to a company that processes payroll, or handles trucking of goods, or shipping (as in ships), or handles your bank account. There is a huge invisible system of code out there that's practically invisible to the users, and most of them never think about it although they encounter it in one way or another everyday (ATMs?)
No, it is not dead. But it is "legacy" for sure... or is it?
Again, depends how you look at it. Nowadays, a lot of people will use Java, C, or anything else instead of COBOL, rewriting from scratch... introducing new bugs as they go along, naturally. That is not saying COBOL doesn't have bugs, and quirks. It does, as much as the next language. Of course it does. But in "COBOL times", companies which took bugs more seriously than usual (insurance, banks) tended to produce higher quality code with special quality service groups; today, there are deadlines where time and budget always wins over quality. Also, these systems were originally developed for longer periods back then compared to the equivalent now.
If some software has been working for 30+ years, where is the incentive to switch? Whole companies went out of business because they ignored the old adage of "if it ain't broke, don't fix it." Many tried to rewrite the thing... then the first rewrite cost a lot, then the second one cost even more... and none of those new & improved managed to replace it. As I said, this industry is fast-burning, and it also tends to forget fast.
In the 70s COBOL was dead or dying soon, C/C++ were going to rule. Then again in the early 80s Pascal was taking over. Then in the 90s it was Java as THE Language...
Think of Unisys Mapper, dBase, Clipper, Cold fusion... do people even remember those? Each one of them was going to be the gravedigger for COBOL.
Taking that into account, and the fact that it is great for processing high volumes of transactions, batch processing or record/transaction-oriented processing, and that one can compile (without errors) a subroutine written 30 years old as managed COBOL code and call it from a managed COBOL.NET should one wish to go Windows and .NET, I'm having trouble finding a suitable replacement for it. (I'm also having trouble finding a Microsoft technology that lasted more then a decade.)
Yes, new COBOL code is being written today. One just has to know where to look.
For those laughing at COBOL, IMHO, it is like laughing at the Egyptian Pyramids, they are there from 5000 years and they still will be there in next 5000 years, while today's "hello world" housing needing 24 controls to work will be deleted, replaced, forgotten next month.
So where are all those COBOL programmers?
Ah, for here lies the rub. The thing is that a lot of them don't have any computing science background. A lot of them are not professional programmers (as in university graduates from a CS/SE program). For the most part, they are people in their late 30's-50's, from all areas of expertise, trained entirely by the company specifically for that job. So they aren't "COBOL programmers" - the training they got is specific to the company which so heavily promotes from within. And that makes them pretty much invisible.
If you can see yourself as COBOL programmer, then go for it. There are still billions of lines written in COBOL that require maintenance.
Actually, there is no such thing as unnecessary knowledge, so broaden the knowledge and wider opportunities you (will) have.
Does learning it make sense?
Well, it's a niche and there's tons of working legacy code that need to be maintained and can't just be rewritten. So while it's not really an option for the vast masses of all programmers, it's a perspective for a steady income for individuals.
However, if you're interested in creating new solutions, rather than slowly improving those that have been around since decades, COBOL probably isn't the right language.
A lot of european companies still rely heavily on mainframes running like z/vse and cobol programs. There is a demand for skilled cobol programmers that noone thinks the market will fill which drives up the salary, a lot.
The question should be, "will I ever develop something new using cobol?" since pretty much everything is maintenance or variations of existing mission critical stuff.
I used to work for IBM where COBOL and PL/I code was written every day. Also from big companies relying on IBMs mainframes like many banks which require thousands of transactions per second those languages are still heavilly used.
If you don't want to work in a place like that (That's why I just worked there for 6 months) then don't even think of learning those languages.
We write new Cobol code every day, and we are on a constant lookout for new programmers. The supply is too small around here.
If you want to have a job as a COBOL programmer, then sure, go ahead and learn it.
For any other reason, like trying to learn something useful that might help you with modern programming techniques, no, don't bother.
In the year 2000 I read a statistic that there were more lines of COBOL written than all other languages combined.
Add to that the IBM guarantee that any TEXT deck (object code), compiled on any MVS system is executable on all of their MVS systems and you have a guarantee that there will be COBOL programming around as long as the sun shines.
I can tell you how I "learned" it:
I was employed to work with it, having no clue what it was about, and had no difficulties learning it overnight.
So, if you need it you can learn it. No need to overload yourself with useless knowledge. There is nothing interesting in it or its engagements unless you have real practical need for it.
The generic answer: learn coding principles, not their specific implementations (like languages, etc.)
I would not spend time over it.
Anyway, COBOL is the building blocks of many legacy application programs that are mission critical for several Big Company started 20\30 years ago.
So, if you are hired for a company that has part of its core business in COBOL, there are chances that you have to start to learn it.
Learn it if you like, after all, knowing how things work (or used to work) cannot be a bad thing.
However I would recommend against emphasizing your COBOL skills too much in your resume.
In some places (for example, in the Silicon Valley where I live) having COBOL in your resume is going to be a liability. Oh sure, you might find a place here and there who need your expertise, and in that case go ahead and advertise it to those places only. But in general, do yourself a favor and forget to mention that you know COBOL.
So yes, learn it if you're curious, just don't tell anyone.
Maybe not worth from a work market perspective, but you might want to have a look at it just to get a feel of how stuff was done "in the good ol' day". ^^
From a personal perspective I would say that there are better things to learn first. However, many large companies have very large investments in their COBOL code base which they'll probably never really be able to leave behind, creating an industry for COBOL programmers to maintain the code base as well as write new code. The company I work for is a large financial company and our technology split for developers is roughly 30% COBOL, 40% Java and 30%C#.
I just did a search for "cobol" on Australia's largest job website. It returned 87 results, and (from a quick skim) they mostly seem to be legacy maintenance positions in banks and financial institutions. Mostly distinctly better paid than more "modern" language based jobs - presumably due to the rarity of Cobol experience.
So yeah, it seems like Cobol would be worth learning if you 1) don't mind doing legacy maintenance and 2) you want to get into a niche which is well paid and probably not very competitive since it's something few people are learning anymore.
(I'm assuming the Cobol market would be similar in most First World economies, but could be wrong?)
Think about the kinds of problem domains you want to work in. Typically those domains have a set of languages that are generally used for the purpose. If COBOL matches that then go ahead.
There is no way I would touch either cobol or the problem domain(s) that use it heavily with a 10 foot pole. I'd rather flip burgers.
Also consider if the language offers some bonus/improvment to your programming ability/concepts. I can't think of anything COBOL can do/implements/features that isn't done better or can be demonstrated better in another language.
You and others may feel differently.
There are still plenty of legacy system out there written in COBOL. Whether you want to maintain them or port them to other programming languages, it is still worth learning COBOL.
No matter what it is, some knowledge in multiple programming languages will be a plus because the knowledge you have allows you to choose a programming language or approach for different project needs. You can use your knowledge in programming languages to construct better, cleaner and more efficient codes and to avoid pitfalls.