One of my last jobs as an intern in 2004 was to rewrite an old batch process COBOL app in C# and ASP.Net. App was basically input about 6 fields, and based up some rules. It really wasn't terribly complicated, but I had to read the source to understand exactly what it did. It was also my real exposure to COBOL. Took me a while to realize that around 60 printed pages of the 80ish page program was nothing but hard coded data tables and rules, when this, then that, etc. Once I realized that, it was a few simple regexs to pull that and transform to xml (was early 2000s...).<p>While decyphering the remaining logic, I discovered what I think is the most evil programming construct I've so far seen; think goto is bad? Meet MOVE NEXT SENTENCE. COBOL is traditionally written in all uppercase (and historically EBCIDIC). So what does "MOVE NEXT SENTENCE" do? It's an unconditional jump to the next period, that's right '.'. Thats right, in a language where everything looks like it's yelling at you, you have to find a little tiny period to find where execution resumes. No labels, just a tiny couple of pixel round period. Fun...
I worked on Y2K remediation fixing COBOL programs I'd never seen before at a large oil company. It's an easy-to-understand language by design. The complexity of dealing with the apps/jobs wasn't the code or the impact analysis, but just the volume of work -- the endless test cases. The nice thing about those systems was that because they were financial apps, success was pretty black or white. Either things balanced and agreed with production or didn't. But sooo many green bar reports. Killed many green bar trees in '98. My theory is that if you like programming, preferences aside, you'll appreciate the beauty in any language, COBOL's no exception once you grok it. May not be sexy but I've seen sexier languages come and go in 20+ years.
> “I think there is a misconception about [COBOL]. A misunderstanding about it as far as it being old. Usually in technology we think because it is old it is irrelevant,” he said. “But it’s still the fastest processing language out there.”<p>I thought this comment was born from naivety or bias, but after reading up on it a little further, it appears that it's true or close to true for many cases.
My first gig out of college was maintaining Cobol at a bank for two years. Some of the programs were 20+ years old, and we made changes monthly - it always seemed like a fantastic rate of churn.<p>If something went wrong during a deployment, heaven help you. One time a pair of transposed digits got through testing and code reviews and into deployment. My colleague spotted it and called the management center to hold jobs... Thirty seconds too late.<p>It took four days to back everything out.
At my last job they had a custom variant of COBOL and hey I don’t know why everyone is playing it down. It was beautiful. You could make a full GUI form with full validations in like only a few lines of code.<p>Like a whole tax form is how you’d do a Hello world.<p>And then we ported the runtime to render web pages over a web socket and that’s when things got really interesting. 20+ MLOC of legacy apps rendering directly to the web.<p>It’s such a flexible language and I absolutely enjoyed working on the run time and the other guys in the company really enjoyed writing in it.
Cobol is mostly likely around because no one knows exactly what the code does. Missing design documents & decisions don't help either. Companies making money are risk adverse, they won't risk killing their golden goose over a rewrite, it's often companies that are not making money that go on massive rewrites believing that new tech will give them the Midas touch towards profit.
I once had a boss who was an old Cobol Cowboy, he walked me through a financial system that's still in use.<p>I can't help but feel that even back in the days, they would have been better served by Pascal with fix point math. The only convenient features I could spot were related to working with records in files, and Pascal has that covered.<p>Their Cobol implementation sort of, kind of supported subroutines but they were such a pain in the ass that code was usually copy-pasted instead.<p>The only thing about Cobol that I just can't stand so far is the optional filler "keywords" that allows code to look sort of, kind of like natural language. That's just wrong.
I had an assignment at the Dutch Tax Service and was surprised to learn that they were still actively developing new software in COBOL. The reason, I was told, was that they had many COBOL developers and not as many that were experienced in other languages. Most of these people, however will start their pensions in a couple of years, so they'll have nobody to maintain this stuff.
My understanding is that part of COBOL's longevity stems from its particular handling of fixed-point math being a specified requirement of various financial contracts. Odd to see this write-up not mention fixed-point math, actually.
> Some banks have spent hundreds of millions of dollars and several years migrating systems.<p>The commonwealth bank in Australia, one of the biggest four banks in the country, spent AUD$1B migrating away from COBOL.<p><a href="https://increment.com/programming-languages/cobol-all-the-way-down/" rel="nofollow">https://increment.com/programming-languages/cobol-all-the-wa...</a>
I'm a bit young to have had any contact with COBOL, but I've worked in financial institutions implementing mission-critical code handling customer transactions in other languages. The first thing that springs to mind to ask is, what kind of features does COBOL offer to make these processes safer and less bug-prone? At least 75% of the code and associated reams of unit testing I've seen written in these applications is to deal with weird input and edge-cases. Is there anything specific about COBOL that is especially suited for dealing with this kind of task? I've never seen anything written about static analysis or formal modelling either. Is the compiler especially attuned to catching potential errors? Is there implicit run-time bounds checking and analysis like in Ada et al?
I was curious if anyone has published a decent chunk of “modern” COBOL since articles and stories never really link to large working systems. It turns out Walmart has! Enjoy: <a href="https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM007.cbl" rel="nofollow">https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM0...</a>
My day job is writing German COBOL, i.e. ABAP. The language changed a lot and is quite usable, except they don't have namespaces. But the worst is all of the cruft that accumulated. Not just of legacy code, but also in the language itself. So many different paradigms, old frameworks, everything is still working. On the other hand it is very high level for the job to be done. SQL can be directly embedded and there is a syntax check. There are a lot of integrated tools that are heaven and hell in the same time. The database migrations are so easy, but source code management, deployment is hell.
Looking at the absurdly long code required to make factorials work makes you wonder what conveniences we are all used to without really appreciating them. And which ones will future programmers take for granted but are too niche now - maybe async/await or the borrow checker concepts, or is programming mostly "done"?<p><a href="http://rosettacode.org/wiki/Factorial#COBOL" rel="nofollow">http://rosettacode.org/wiki/Factorial#COBOL</a><p>or also <a href="http://rosettacode.org/wiki/FizzBuzz#COBOL" rel="nofollow">http://rosettacode.org/wiki/FizzBuzz#COBOL</a><p>Is there a code example where Cobol shines in comparison to, say, Python?
3 years ago I learned that large insurance companies in India still use COBOL. That fact blew my mind. This fact (Estimates as high as 80% of financial transactions use... COBOL) further blows my mind as I thought only Indian financial institutions are rigid. Clearly not.
If your company is looking for training materials for COBOL or other mainframe technology, it might be worth taking a look at Interskill.<p><a href="https://interskill.com/" rel="nofollow">https://interskill.com/</a> or <a href="https://interskill.co.uk/" rel="nofollow">https://interskill.co.uk/</a><p>Disclosure: I work for them.
I've heard this sentiment about Cobol often. As someone who has never seen Cobol or used it, how hard would it be for me to specialize in Cobol maintenance and porting? Is it really as impenetrable as it seems, requiring years of experience, or can someone like me work through a few books and get on it?<p>With this kind of thing you never know when organizations move away from the technology en masse and it would be great to be in it at the time.
My first programming job (29 years ago!) was a COBOL gig. I worked for a company that wrote banking software, most of it COBOL and a little Assembler.<p>It all ran on IBM mainframes (the size of a small car) surrounded by disks and controllers the size of refridgerators. All the hardware was kept in a glassed-in room with white-tiled raised floor. Most of the coding was done on dumb terminals, but a few applications still had punch cards.<p>Ah, the memories. Long live COBOL.
From what I understood when I worked at LiveNation, every time you buy a ticket from Ticketmaster the transaction flows through some ancient spaghetti COBOL, probably running in Phoenix.
I <i>really</i> want to get a job writing COBOL. However, nobody will give me a chance at it. I recently applied for a few jobs in my area but they wanted 10+ years of COBOL so I was turned down. I learned in college (however would need to re-learn) and I really enjoyed it. I also enjoy financials and data.<p>If anyone has any thoughts I'd appreciate it. I'm currently writing c++ software for making robots work, plus I have financial industry experience.
I've had a limited exposure to COBOL and I consider it quite elegant for the problems it's trying to solve, particularly for column oriented transactional data processing, I found it interesting that on System Z, all of the IO, is done in the JCL that you use to start the program, not in the program itself.
I hate how the title says "powers the global economy" when it should be "powers banking systems". I spend a lot of money on many things, my smartphone, gsuite, slack, Netflix, Amazon, Dropbox, games, tools, hardware, and I would guess most of that stuff never touched Cobol. Meanwhile I pay 1usd monthly for my bank (which, btw already migrated). So saying it "powers the global economy" is definitely a bit of a stretch.<p>I am sure there's a lot of it running still, mission critical stuff, also that there are still a few teams creating new projects with it. So it is not dead by this definition. But if I'm honest, I can't name one single language that is.
The term from economics that describes the situation well is "switching costs". They're very high in this case, as comments regarding banks migrating away indicate.<p>This book is a great overview of the economics of these kinds of situations:<p><a href="https://en.wikipedia.org/wiki/Information_Rules" rel="nofollow">https://en.wikipedia.org/wiki/Information_Rules</a>
...because people aren't willing to change it.<p>That doesn't make Cobol sounds less like a fossil in any way. It will be go away eventually.
What an incredible website<p>The audio version has the quotes in the voice of the original speakers (probably because this is a radio).<p>There is an interactive timeline custom made for the content of the article.<p>Other audio logs can be accessed super easily via the drop down menu.<p>Incredible stuff.