Are you an unemployed software engineer?

[schmitt trigger]

There is an exciting *new* opportunity for you: COBOL!

I kid you not:

https://www.cnn.com/2020/04/08/business/coronavirus-cobol-programmers-new-jersey-trnd/index.html

Willing to work long hours on tight budgets and antediluvian computers.

[brucehoult]

I am!

And I even got paid to write a COBOL system for Whangarei City Council during my university holidays in 1982/83. The task was to automate the generation of a list of payments to be made that month for all the loans / debentures the Council had raised at various points to pay for things such as water works improvements, mostly from private individuals, but also from insurance companies. Many or most were on a 30 year term so at that time some loans from the early 1950s were still alive, and some new ones were running up until 2010 or so.

I'm happy to report that I made sure the code was Y2K-proof :-)

I've sometimes wondered whether that stuff is still in use.

[golden_labels]

What I find funny is that COBOL was created to be used by common people with no experience in programming and now someone asks for programmers to write software in it. It seems it missed the goals.

[bsudbrink]

Yes and object oriented programming was going to make code clear and always easily reusable. <snicker>

[ataradov]

Banks use COBOL for their backend stuff. They are slowly moving to other stuff, mostly Java. I'm guessing they will be done when Java is also obsolete.

At the same time COBOL programmers get paid very well, since it is hard to find them and nobody wants to learn dead tech.

[ataradov]

What I find funny is that COBOL was created to be used by common people with no experience in programming and now someone asks for programmers to write software in it. It seems it missed the goals.

It achieved  its goal for a time it was invented. Better things came along later, as it always happens.

I would not recognize COBOL code if I see it, but I bet it is not that hard to figure out. It is just a pointless waste of time, unless it comes with a huge pay.

There is no absolute time-proof technologies. It must be on the code owner to maintain and update it once in a while.

[coppice]

COBOL is still a good language for a young person to learn. There is demand, but most youngsters want to be working with the latest and greatest fashion. That means the jobs tend to be really well paid. If the demand for COBOL ever goes away, a capable experienced COBOL programmer won't take long to pick up whatever is the language de jour.

[TK]

COBOL is a very verbose language, very easy to understand.  In my opinion there is a need for COBOL programmers for mainframe, including CICS transaction processing system and DB2 or other vintage database systems.  Just COBOL is very easy and can be learned in very short time.

[james_s]

COBOL was developed in the 1950s, the fact that it is still in use and there is still demand for COBOL programmers says something I think. I've never played with it myself but obviously it gets the job done.

Does anyone think Javascript or Swift will be in common use 70 years from now?

[golden_labels]

COBOL was developed in the 1950s, the fact that it is still in use and there is still demand for COBOL programmers says something I think. I've never played with it myself but obviously it gets the job done.

The reason it is still used is because there is a lot of systems that were not updated since tha time, not because it is such a great language that new things are being developed in it. Since most of it is not directly exposed to network or any untrusted data, it’s not a problem — those systems may as well run fine for the next 50 years, giving jobs to generations of peole knowing obscure languages.

[brucehoult]

COBOL was developed in the 1950s

Not "the 1950s". The committee to design it was started in April 1959, the initial specification was published in January 1960, and the first two implementations were able to run a standard example program in August and December 1960. Widespread adoption was some time later.

Let's be generous and use 1960 as the date. That's 60 years ago.

the fact that it is still in use and there is still demand for COBOL programmers says something I think. I've never played with it myself but obviously it gets the job done.

COBOL was designed to represent the problem domain, not to reflect or be influenced by current computer technology at the time, even if that meant it was inefficient. This is a good thing for longevity.

Does anyone think Javascript or Swift will be in common use 70 years from now?

JavaScript was designed and deployed to millions of users within a few weeks in 1995. That's already 25 years ago, so it's only got 35 years to go to match COBOL today.

Yes, I hate the idea, but I'm sure JavaScript will still be supported in every web browser in 35 years from now, and used by huge numbers of web pages.


C is from 1972, which makes it 48 years old. I'm absolutely confident it will be still in wide use in another 12 years.


Swift is a tougher proposition. It has a lot of competition as a high performance applications programming language (replacement for C/C++) from Go, Rust, D, C#, Java, Kotlin. Swift is a bit more advanced and powerful than most of those, having taken a lot of influence from the ML, CAML etc school. Apple has invested a huge amount in it since 2010 (public release in 2014), the compiler and libraries are extremely mature and optimised, it is open-sourced and available on Linux and IBM's mainframe z/OS (as a competitor to COBOL). I don't think Apple will switch to anything else any time soon, which makes it a major language for as long as the world's largest and most profitable company stays in business and important. Will that be 50 or 55 more years? I don't know. That's a long time. I'd be very surprised if it's less than 20 or 30 years though. Learning Swift is one goal of my current funemployment on the list I made a month ago :-) (along with FPGAs, Webasm, and Go)

[schmitt trigger]

I also learned COBOL while in college in the mid-1970s, although never used it professionally.

COBOL is a little the old Volkswagen Beetle. A severely outdated platform, but got its job done, once you were aware of its limitations. And simple to understand.

[bd139]

"Literally, we have systems that are 40-plus-years-old," New Jersey Gov. Murphy said over the weekend.

Well that makes me feel a shit load better about the 15 years of technical debt I'm hacking through 

Seriously though if you're having problems finding people to look after your stuff because it's literally that old that no one is interested it's time you hired some consultants in to reduce that business risk by replacing it. If you got to the point that no one understands what is left, a problem I see regularly, then you fucked up. Thus this is a fuck up.

I worked with a company that had half their internal ERP ops running off a single AS400 node back in about 2003. That was at the time about 10 years old and they had no staff who even knew how it worked and someone had not paid IBM any money for at least 5 years. I migrated it and their equally obsolete netware setup to windows XP / 2003 and SQL Server / ASP.Net.

[SiliconWizard]

As I said in another thread, COBOL is not dead: https://en.wikipedia.org/wiki/COBOL

And COBOL-2014 has a lot more than what it was in the 60s.

It has also proven for decades that it worked for this kind of applications. Why switch to languages that have a long track record of software security issues and nasty bugs?

[chickenHeadKnob]

I am!

And I even got paid to write a COBOL system for Whangarei City Council during my university holidays in 1982/83.
.. snip ,,

I'm happy to report that I made sure the code was Y2K-proof :-)
I've sometimes wondered whether that stuff is still in use.

I am no longer surprised at the common life experience I have with some forum members. My first paid programming job was fleet vehicle maintenance records and statistics system built from the ground up in COBOL during summer holidays 1979. The summer job was instigated by a mechanical engineer who wanted to light a fire under the computer services department which was stalling him. So I landed into this political mess,  I was all on my own and had to fight the people who controlled access to the Univac 1108 mainframe and who wanted to see me fail, but I didn't.
My code was for sure not Y2K proof, two digit year codes everywhere for the win!. Also I never wonder about it as the company went under some 20 years later

[bd139]

Why switch to languages that have a long track record of software security issues and nasty bugs?

Productivity, integration, cost, staff availability, better tooling, better user interface.

You can write bugs in COBOL too.

[SiliconWizard]

I'm happy to report that I made sure the code was Y2K-proof :-)

Hehe, good job.
But anyone designing financial software in the 80's not Y2K-proof (so that would be less than 20 years ahead - which is pretty average for a real-estate loans for instance) would really be ultra short-sighted. Glad you were not.

[james_s]

Why switch to languages that have a long track record of software security issues and nasty bugs?

Productivity, integration, cost, staff availability, better tooling, better user interface.

You can write bugs in COBOL too.

Don't underestimate the cost of replacing the whole  system though. I'm sure any of us who have been involved in tech long enough have seen some sort of boondoggle where and old but still functional system was replaced by something new for the sake of being new. The whole thing vastly over budget, rife with problems, etc. If I were starting from scratch I'd never advocate using an obscure language but it can be hugely expensive to replace an entire legacy setup and sometimes the money just isn't there.

Besides, as passionate as some people get about programming languages, it all ultimately boils down to machine code anyway. What can be accomplished in one language can usually be accomplished in another though maybe not nearly as easily.

[bd139]

I think the issue apart from cost is usually the idea of replacing the system with one identical built in new technology rather than building a new system for the business requirements of the day. If the money isn't there then the business is a failure. Typical of companies that see IT as an operational cost rather than an advantage.

I knew a small business here in the UK that learned that the hard way when they had an EOL legacy system fail on them. They didn't budget anything for their IT provision to replace it preemptively, ended up with a £2m bill because no one would poke the steaming pile with a stick and had to fold instead. If you operate your business under any reasonable quality framework rather than sweeping business risks under a rug then you tend to do better. The money being there is no excuse. That's how you screw your customers and employees.

As for all of this, the most expensive bit of any system is the humans. So I'd rather give them tools which give me the best time to market with cost and reliability compromises as a whole. It's 2020 so you almost always have to integrate with numerous 3rd parties.

[james_s]

Well, yes that's not wrong, but it also ignores reality, sometimes the money just isn't there, so what do you do? Close down a business that is still paying the bills because you decide it's a failure that you don't have the money to upgrade? A failure can be catastrophic, you just have to hope that doesn't happen.

It's not much difference than someone who patches up their house or gets by with an old obsolete service panel (consumer unit). It might make sense in the long run to upgrade to a modern one rather than trying to add another circuit to what you've got but when the upfront cost is an order of magnitude greater many people simply don't have the money.

[bd139]

Usually you hide it from your customers, go bankrupt and take them with you in corporate America I understand 

[free_electron]

You really think that banks , which run big-iron' are going to switch to script-kiddie languages like python ? no chance ...
Time is money. It has to be rock-solid, deterministic and transactions need to be guaranteed and atomic. Cobol was designed for all that. There is no wiggle-room.

[bd139]

I was a principal solution architect at a clearing bank here for ref. You couldn’t be more wrong.

90% of it was java backed on DB2. The rest was python and shell. There was no COBOL. Even front office was java SE.

As for atomicity you have to consider a much much larger scale transaction architecture than the scope of a single chunk of cobol. All banking systems are “eventually consistent” architectures so there are transaction and reservation arbitration processes Instead of atomicity.

[TK]

I agree with bd139, COBOL as language is not what makes Banks, Airlines and other large enterprises keep legacy systems.  It is the surrounding environment (Very robust and reliable hardware - mainframe, proven OS - MVS, proven volume transaction system - CICS, robust database and storage - DB2, VSAM).  You can program in COBOL, Assembly or any other language that was available in the same robust environment.

[bd139]

Yep. It’s even moving away from some of the traditional “reliable hardware“ as it’s too expensive and difficult to scale out. Two of the major banks here have significant Kubernetes clusters replacing zSeries and moving to redundancy at a software level.