The code that controls our money | Hacker News Reader

The code that controls our money

wealthsimple.com

I am suspicious about the alleged problem finding people willing to work with COBOL.

Generally, if it's crucial for the business, the lever you pull is increasing compensation until the market responds. That's how you influence willingness. People are willing to do much dirtier jobs given enough money.

"But we need someone who is not only willing but able," they say, meaning they want someone with many years of experience with the language.

These same companies did not invest the time or money to train future maintainers in the language or make it worth their while to accumulate that experience. Guess what happens when you don't invest that money up front? You pay for it dearly later on.

So it's either an impossible situation of their own making, or those elusive COBOL programmers are out there, but companies significantly underestimate how much they really need to shell out for such a specialized skill set.

Either way, I don't think the problem can be reduced to younger programmers wanting to write code in the hip newer languages.

Best case scenario is they go broke and decommission the obsolete system, with it being replaced by a competitor using better tech or planning, or leaving an opportunity in the market for such.

This is a microcosm of the "STEM shortage" in general.

Socialize the losses/costs (publicly-funded school), privatize the gains/profits.

That said, there's a different side to the issue, which is that smaller companies do not (and never did) have the resources to train people. There definitely is a shortage of senior management-capable technical people who can lead projects and teams at smaller organizations. This however isn't relevant to big banks and Cobol.

There are huge incentives to talk up a shortage in X because the labor market self trains. So, no we’ve never had a nursing shortage etc, but talking about it is a great way to save some money.

The only signal worth paying attention to is industry salary trends, but reporters rarely have the time or incentives to actually do real reporting.

The thing is - the bank referenced in the story has COBOL programmers, but they kept recalling the effective COBOL programmer.

That's the issue with self-training for mission critical systems. Sure, some people can self-train, but a company doesn't want to pay people to learn on the job, while thwey are counting the beans.

I’m generally pretty amazed at how low the salaries are for COBOL developers relative to the criticality of the systems being maintained, and also how common those legacy code bases are.

Right. This is a "shortage of Lamborghinis... at the $10,000 price point."

There is a "shortage of housing in SF ... for $100,000."

If the going rate for COBOL programmers was towards the top of the Software Engineer market, that would be an apt comparison. Trouble is, the going rate for COBOL programmers is at the bottom of the Software Engineer payscale.

The HN consensus has been that there is no shortage of labour as long as you can just pay more and get the labour. Even the fact that prices are consistently increasing doesn't mean that there is a labour shortage. It's only a shortage if you cannot buy labour at any price.

It is not what you specifically are arguing here, but I have read different iterations of the above dozens of times on HN and it is always highly upvoted and almost all comments are in support of this position. I find it interesting that you can just pay more to buy or rent in SF, so by this definition there is no housing shortage in SF.

But surely there is a shortage, and you can't just pay more.

My mom knew COBOL. She retired in the 1970s. You're going to have a tough time hiring her now.

I've never written a line of COBOL, but pay me enough money, and I'll be up and running in a mainframe terminal by the end of the month.

Looking at in.indeed.com, you can make ₹10,00,000 or more per year. Up to as much as ₹25,00,000.

...but that's if you have "3-5 years of Experience in Cobol, IMS, DB2, JCL".

I imagine an entry-level job might pay ₹7,00,000 or so, if you can show sufficient coursework in COBOL?

Some quick googling shows that ₹10,00,000 is about $13,560 USD.

edit: I made the mistake of multiplying this by 12 originally since I didn't read carefully.

The commenter specifically said that the Indian salaries are per year. So they definitely underpay even for the Indian market, given salaries for non-COBOL.

You're right, not sure how I missed that.

One might ask, setting aside the task of getting accurate and representative numbers, because that's too much work, what do Indians believe is plausible?

Some people are surely trying to set expectations low, while others may be exaggerating what you can make with a few years of experience.

However, I've seen quite a few different sources claim an entry level developer makes around 4-10 lakh rupees a year. This makes me think they think their audience considers that good but not unbelievable.

And then when somebody claims you can make 60 lakh or more with 5 years experience, it makes me think that their audience knows roughly what US salaries are, whether or not the figure is realistic.

I think the confusion stems from the fact that India has a surplus of IT employees. The sheer number of universities and software graduates is hard for Western countries to imagine.

As such, you will see a massive salary range, anywhere from 3-60 lakhs per year. It’s hard to calculate based on experience - tenure, tech stack, or otherwise.

The lower end is dominated by body shops that take the bulk of offshored projects, since that’s exactly what Western companies want. The higher end is dominated by FAANG and VC funded startups. Moreover, the majority of companies do not have significant yearly raises, and jumping jobs is the often the only solution.

Learning COBOL doesn't require you were born in the 1940s though. If COBOL jobs were paying what "AI" jobs are now, more people would start learning it.

A shock or major unforeseen event could cause a shortage for a time. But we've been hearing about the dire shortage of COBOL programmers for 30 years or more haven't we? Yet in that time apparently they haven't either migrated their systems off COBOL, started paying people more, or decided they don't need to invest as much effort into it? Doesn't seem all that credible.

Well, yes, you've cleverly deduced there is no real shortage.

There aren't any significant number of people wringing their hands over it for 30 years either.

You're welcome, glad I could clear that up for you.

Local vs global.

>The HN consensus has been that there is no shortage of labour as long as you can just pay more and get the labour.

I guess I'm on that side, for the following reasons - the companies that want Cobol are companies that are pretty rich. Yet, Cobol salaries are on the low end for Software developers.

>I find it interesting that you can just pay more to buy or rent in SF, so by this definition there is no housing shortage in SF.

there's no housing shortage in SF for billionaires who are willing to pay whatever is asked. Did I mention my perception that the companies who want Cobol programmers are really rich.

Now, it may be that there is an actual Cobol shortage, I would even agree that it is likely because at the rate offered not very many people would be interested in learning a language generally derided and not much like other languages. But we cannot know that there is an actual Cobol shortage when the rates offered are less than those for Machine Learning experts.

If you offer top rates for Cobol programmers and can't get them, then you have a shortage.

Many governments use COBOL too, governments are theoretically rich, but they also have many holes to fill.

good point, I don't have a good metric for weighing how much government benefits would increase the value therefore it might be that there is enough money on the table for gov employees that there can be said to be a shortage.

There is a sense in which you only get a shortage as a result of something like price controls. If Saudi Arabia stops producing oil, the price goes up, but you can still get it. But if the government institutes price controls then people buy all they like at that price until the supply runs out. Then you can't buy it at all because nobody who has it wants to sell it for less than the price cap and nobody is allowed to sell it for more.

There is another definition of a shortage which basically says that supply doesn't respond to price, i.e. even if people are willing to pay more, the total amount of supply doesn't increase.

If gasoline was suddenly $50/gallon, it wouldn't stay there very long because it would immediately be profitable for new supply to come online, using production methods that aren't economical at lower prices. Supply would increase in response to higher prices.

This is also true of COBOL developers. If they were highly paid (relative to other software developers) then more people would learn COBOL and the supply of COBOL developers would increase in response to the high price.

It isn't really true of housing in SF. The price goes up and the supply remains the same because new construction is constrained by zoning. So there's a shortage.

> The HN consensus has been that there is no shortage of labour as long as you can just pay more and get the labour.

The problem with this argument (as a native German speaker) is that in German, there do exist two different concepts that are both translated with "shortage" in English:

- [die] Knappheit

- [der] Mangel

"Knappheit" is a sign of an efficient market: if the supply decreases or the demand increases, the prices go up, so only the buyers that are willing to pay most get their share. This makes a market efficient.

"Mangel", on the other hand, means that (nearly) no matter how much you are willing to pay, you cannot get the good. This is a strong sign that the market is broken (often because of regulations).

Of course the media in its agenda loves to confuse these two concepts and writes of "Fachkräftemangel" ("shortage of professionals"; even though "Fachkraft" which I translate with "professional" here, actually literally means "field [field of study] force"), hiding the fact that there are no signs of Mangel, but of Knappheit.

If coding salaries get higher, more people go into coding. (We're actually seeing that happen already). Whereas it's de facto illegal to build homes in SF.

I thought I read somewhere that there are schools in India teaching COBOL more recently.

So I wonder if it's something like manufacturing in China - it's not just cheaper, it's that the expertise has moved.

You can't incentivize American programmers with a lot of experience by throwing money at them, when they retired ~50 years ago.

I signed up for a COBOL course at a state university around 2000, but dropped it without ever attending a class. I think they still had line printers.

At one point I was amused that there seemed to be a standard for object oriented COBOL...

It's my understanding that many of the Indian body shops like Tata and Infosys do COBOL work. When I was an intern at Adobe, one of the other interns was Indian and had spent the last summer writing COBOL at Infosys. He was glad not to be doing that anymore, and I suspect engineers in India are looking to learn better-compensated skills just as in the U.S.

I’ve always been told it’s an incredibly bimodal area. You have the guys the company can snag at $60k a year while their career stagnates and they become stuck and then consultants who worked with these systems way back in the day, may even be retired, but can charge insane consulting rates.

> ...relative to the criticality of the systems being maintained,

Someone writing COBOL for one such critical systems told me that there are two testers in their company whom they have never met and that no real testing happens(just some basic code review) because their company charges the client every time a bug is found to fix them.

But they did say that their client do call their retired employees to clarify some doubts just like this often shared article states.

And aside from that, who wakes up one day and decides to spend their lives wallowing in a dying programming language to work in the illustrious field of maintaining 30 year old banking systems as an underpaid code monkey whose skills are largely nontransferable to other sections of the information technology industry?

Yes but also no. How can they find senior COBOL developers if there are no Junior COBOL jobs? Sure someone might pick it up for the money but they will not have “X years of experience” required to work on incredibly sensitive money systems.

Eh, with COBOL I can just see them not existing at a reasonable price point and not having any avenues to gain the experience from senior people.

Say that you have a pair of chickens that people really want chicks from. Pay whatever you want. You cannot really speed up chick production because of that initial bottleneck.

The problem is real, for many banks, but it’s not as big problem as it would seem.

I know one bank who does an academy thing, where they bring in graduates, train them for up to two years (with salary) for them to be able to work on the systems. So, it’s a problem, but they have knows to get around it.

Also. This problem is not isolated to banks. I saw the same kinds of problems when I was in telecom.

"That's how you influence willingness. People are willing to do much dirtier jobs given enough money."

Sort of. I dealt with a large smalltalk system with it's own datastore. Finding smalltalk devs was painful. Training new ones? It was a mess. The dev environments didn't seem to port correctly to modern linux systems - mac? forget it, we could never work out contracts with Cincom Systems to get proper licenses - they would demand us pay a portion of revenue with audit rights (wtf), staging environments were layers of hacks, smalltalk could work on port 80 but making it work with apache/nginx/load balancers was always a mess, smalltalk itself was covered in bugs and would crash for no apparent reason. All new devs knew learning smalltalk was a waste of their future job prospects - they also had no good mentors. Good luck finding things on stackoverflow. The smalltalk contractors that could help would just raise their price so high it turned into extortion (one of them even wanted a portion of gross revenue). These contractors would delete histories, use hand written journals, hide documentation, refused to train anyone, not use version control, quit in the middle of meetings -- and they all were friends - it was a total shakedown. "Just pay them more" never really worked out for us.

My uncle was a smalltalk developer for a while - growing up I never realized how unusual that was. What kinds of things is it used for these days?

> A company might as well spend months of their experienced developers' time while making them mentor the more junior devs and invest a lot of resources in this, as well as have more overhead to their development because of needing to spend longer on QA and fixing bugs introduced by these juniors, for them to just turn around and leave when they've gotten the seniority that they desire.

Then they behaved like Oracle, Terradata and every other "business-sensible" vendor, who manages to get his customer into a technology-based lock-in. The only way Oracle only shakes down customers for tens of millions per year and not for billions is that, if it were billions, companies would just invest into migrating off Oracle.

Money is not the primary motivation for doing something. This is big myth. In all surveys where I come from, money comes quite a bit down on the list on what employees look for in a job. Additionally, there are factors that might be surprising, like trends (what is considered "cool", or "correct" or "noble" etc).

> Money is not the primary motivation for doing something. This is big myth.

This depends on the culture, how honest those people are being, the greater economic situation of the people in question and many other factors.

For a general overview, the StackOverflow developer survey (n=65'000) seems to suggest that about 70% of the respondents feel like compensation indeed matters a lot, more than any other factor: https://insights.stackoverflow.com/survey/2020#work-job-hunt...

> For the first time, we asked developers what drove them to look for a new job. Better compensation was by far the most common factor for respondents with 70% of them noting that more pay was important. Wanting to work with new technologies was the second most popular factor, which is consistent with what respondents reported as one of the most important priorities when choosing between two jobs.

Curiously, they skipped that question in the 2021 survey, so it's not included at all.

I can personally understand this viewpoint, seeing as i don't receive all that much money either and it would take me about 40 years of constant work to be able to afford my own house with my current earnings and small raises here and there. Plus, with my current salary there's no way i could afford, for example, cancer treatment or to address any of the other serious health issues that can arise in people.

It's probably higher up most people's list than 'programming language I will be using' though?

> Guess what happens when you don't invest that money up front? You pay for it dearly later on.

But that's the thing - these companies don't expect to be the ones to invest in these developers over the years, to let them upskill themselves. Neither do other companies. If you look at /r/CSCareerQuestions, you'll find that many of the younger devs are having quite a lot of trouble finding work, very few companies wanting to invest in the start of their careers, since they might as well just look for the more experienced devs out there.

But why is that? Simply because there is no actual guaranteed return on such an investment. A company might as well spend months of their experienced developers' time while making them mentor the more junior devs and invest a lot of resources in this, as well as have more overhead to their development because of needing to spend longer on QA and fixing bugs introduced by these juniors, for them to just turn around and leave when they've gotten the seniority that they desire.

In essence, all of this investment will return this company absolutely nothing and instead will benefit the next company that this developer goes to, which might as well be their direct competitor. Why should companies take this risk, instead of letting other companies do so, train the juniors for them and simply pluck skilled devs from the market when they become available?

I don't condone that approach, but it feels to me like a zero sum game, especially in a competitive market.

I don't have any solutions to offer, since in my eyes preparing devs should be the work of universities AND some other institution after getting their education, that would bring them up to speed to actual industry practices (like bootcamps, but for people with basic knowledge of academia).

Yet, even after getting my Master's, in lieu of such an organization, i simply had to get the practical skills over many evenings and weekends, as well as worked as a developer thanks to one of the companies that did take a risk on me, all while i was also studying. Having to work in the evenings and weekends seems a bit silly when compared with other industries, but with how much churn there is in regards to tech, i don't see alternatives.

There's simple solution to people leaving - just pay them above market rates. In my current company, a manager had this crazy idea, and what do you know - a lot of the key people he hired (most of them were excellent to begin with, as when you advertise above-market pay, you attract some pretty great people) are still with us 5 years later, and are being the pillars of their teams and of entire departments.

Expected earnings is what you think you'll get for this job plus what you think you'll get for jobs further down the line.

Even if a COBOL job paid a lot you wouldn't expect to hold it forever and there's a fair chance you'll have issues getting the next job if you haven't done something more common.

In the 1980s I worked for a Cobol programmer (Tom wrote accounting software for Wang VS systems, I wrote the user manuals). (Just writing that sentence makes me feel old.) I recall that one of our clients was migrating from an even older system that used wire plug cards. Literally no one knew how they worked; if one wire came out of a card, good luck getting it back in the right place. At least Cobol is more comprehensible than that.

As someone who often cannot repair my own breadboard projects if they come unplugged I understand this all too well. It might have been unfixable as soon as it was out of the builder’s short term memory.

Apparently a company in Texas was still using the IBM 402 in 2012, which works just as you describe. Swappable trays of wired patch panels for programming:

https://www.pcworld.com/article/249951/if-it-aint-broke-dont...

This is an interesting product of the power that automation gives a single person (or few people). If it takes a thousand bank tellers to process a hundred thousand transaction daily, then hundreds of them can leave and things will be fine. Whoever oversees the program can ask people questions when they forget the program details (because the program runs smoothly). If it takes a single programmer's work to do the same thing, you aren't going to put two people on it, but that person will someday leave. I wonder if that alone makes things more brittle.

Take it from a guy in a company where single people do a lot of things:

Yes. Yes it does.

EDIT: again, of all the things you could downvote... I just don't get why it would be this post

> I just don't get why it would be this post

Likely because it does not add any extra info or points and is just "I agree"

It actually isn't, it's me confirming that this happens based on my experience.

The post is like one tweet in length and composed of short, common English words. I don't see how it's such a hard post to read and interpret accurately.

> It changed who could write it, too. COBOL democratized coding; companies could take everyday people and train them to be useful COBOL programmers in a few months, and to become experts in a year or two. This was crucial given that companies desperately needed more warm bodies to write software.

> “You could pick people up out of the street,” says Jon Pyke, a British coder who learned COBOL back in the 1960s, “and basically and teach them how to do it.”

Well then. This does seem to suggest a solution...

Honestly, this article kind of makes me want to learn COBOL. In my fantasy, the employers desperation somehow makes it a low-stress job, like they know they don't have time for BS, they have to prioritize the most important things and just let you do your job. And they'd be so grateful.

If COBOL were that effective, you'd see derivatives of it in modern day usage. The COBOL misunderstanding is that the hard part of computer programming is the grammar we use.

I never had much interest in COBOL, but I really liked Hypertalk's pseudo-english code and sometimes wish it had more influence.

I learned to program in hypertalk as a kid, and I am so glad that it never took off.

Why are you glad that it never took off? That's the opposite of what we usually hear from former Hypercard users...

I mean, it did take off, it just petered out after Jobs returned to Apple.

"HyperCard was created by Bill Atkinson following an LSD trip."

"HyperCard had a significant impact on the web as it inspired the creation of both HTTP (through its influence on Tim Berners-Lee's colleague Robert Cailliau), and JavaScript (whose creator, Brendan Eich, was inspired by HyperTalk)"

https://en.wikipedia.org/wiki/HyperCard

COBOL must be effective, since it is used to great effect in these mission critical systems.

> And they'd be so grateful.

Or they'd be a bunch of entitled a-holes and constantly try to manipulate you to extract as much value as possible. As finance execs do.

“Hey cost centre, get back to work.”

i said it was a fantasy!

But yeah, to have any chance at all, you have to wait until it's really a crisis for them (that can't be blamed on you becuase you aren't there yet), like what might happen in 10 years or so from now, and then show up as a knight in shining armor to rescue them.

but yeah, just a fantasy ha.

I agree, it's nice to think that business types might realize they should treat you nicely if their business literally depends on it.

>This does seem to suggest a solution...

Yeah, some already figured out, if you do that, you don't need people from high wage countries.

>The Bank of New York Mellon in 2012 found it had 112,500 individual COBOL programs.

OG microservices.

I was auditing a bank’s data center once and found a working VAX that some guy had managed to keep off the inventory (along with a hundred other servers - he had his own little fiefdom going). The data center techs didn’t know what it was or who was responsible for it so they had just left it alone for as long as anyone could remember.

Are there compelling reasons that these systems can't be broken into parts and then each part gets gradually replaced in turn?

Clearly some aspects will be tied together, so for them it's all or nothing.

It does feel like these companies have got to bite the bullet and get started, otherwise that facade of being conservative will fall, to reveal recklessness.

I suspect it's less of a technical issue and more of a people issue. Nobody wants to take the responsibility if it fails because of some undocumented/unforeseen behavior that only happens in production

Most of these organizations can't tell the difference between competence and incompetence, so any money they spend on IT is likely to be wasted. The more ambitious the project, the more pointless it is.

Maybe it's different in other countries but certainly in Australia, banking is a heavily regulated industry, so replacing a banking host (or even parts of a banking host) would require lots regulator approvals and sign-offs (regulator has to sign off all of the technology and the code that will be run - for existing systems, all changes still require approval, but the initial hurdle of approving something new was dealt with a long long time ago).

I knew COBOL was still in use, but this is astounding:

> The Bank of New York Mellon in 2012 found it had 112,500 individual COBOL programs, constituting almost 350 million lines;

Could that really be true? Can anyone provide some context to make that make sense?

Some speculation: they wrote everything as a separate COBOL program even if it’s the equivalent of a short script, some programs are much longer than others, and there is a lot of duplicate code.

A large bank like that has dozens of lines of business, and each line of business has several processes that are automated. Then there's reporting, auditing, billing, statement generation, archival, etc.

As a bank, you also do all this stuff internally to pay your employees, contractors, create audit trails, document things, keep track of office equipment and supplies, etc.

All the things that other companies might use commercial software for, or just use Google sheets or email or another generic solution, this company has a long-established COBOL program for.

Are all 112,500 programs used? Probably not. But are 10% of them used at least once a year? Probably.

There's probably enormous amounts of duplication there

Most of those cobol programs are doing something equivalent to a single SQL query.

And Cobol programs are _verbose_. Have a look at the examples on Rosetta code. C# (which isn't particularly concise) can do in 40 lines what Cobol needs 250+

Where we (modern programmers) would write a program with a large number of modules and imports, most Cobol programmers probably wouldn't. There is a lot of copying-and-pasting going on there.

That's an average program length of 3000 lines. Imagine your code base consisted of 112,500 files, each of about 500 lines (including HTML, CSS, SQL statements and "real" program code).

That's about what it is equivalent to.

Plugging that equivalent number into a Cocomo calculator, it says "20 years of 800+ programmers".

Thanks, this is good context!

> Plugging that equivalent number into a Cocomo calculator, it says "20 years of 800+ programmers".

Of course, it's been 50+ years, but I doubt Bank of New York had 300+ programmers working for them all those years?

It would make sense if copy-paste were a lot of it.

Which makes me think if you did want (or more likely have no choice and need) to make some serious changes to the codebase, some kind of automated assist could be very helpful. I wonder what the state of COBOL tooling is. I wonder if it's going to get better as the technical debt comes due in a hard way.

The challenge is not the individual program but how it all fits together to make the business work. It may be easy to find people to turn out Cobol code but it will take a long while to fully understand a beast with million lines. Fun bit: Some of these lines only run once a year during holidays so one better makes no mistakes here.

Happy to work on COBOL. Happy to prove ability. Will accept a salary of $2M/year minimum. Contact info is in my profile.

Too much? Then I guess you do not need it enough...yet

Back off! I'll do it for $750k, but only if that includes paid training.

Sadly at only 200k/year there’d be a huge line of applicants.

A lot of people will be weeded out by the main job requirement: we hand you a computer and you figure out the rest, because we have absolutely no idea what's going on. (Or you can head up to Toronto and chat with Tom, if he's still alive)

EDIT: truly, truly confused by the downvotes I get these days. Does someone pay you people to follow me around and downvote my most harmless, mildly interesting posts?

Does hacker need even support downvotes? I only have an upvote button.

You get to downvote if you get enough karma from your posts being upvoted. But a certain fraction of users seem to get a power trip from this, and downvote absolutely anything that doesn't tickle their fancy just so.

Please don't take downvotes on innocuous comments personally. Someone will come by and randomly downvote. Why? Who knows? A few minutes later someone else will restore the balance. On the other hand it's really annoying to read complaints about downvotes.

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

https://news.ycombinator.com/newsguidelines.html

You need to have karma above a certain threshold. It used to be > 500 (not sure what it currently is) https://github.com/minimaxir/hacker-news-undocumented#downvo...

Me too. I don't know a thing about COBOL, but my aunt does and I'm sure she will teach me. I'm willing to learn for that salary.

I was a contractor at cap1 (of credit card fame) 1990s. Learned some good and not so good stuff about how CC corps think about their clients. Anyway on tech/biz side:

- most cc stuff run on cobol code

- cobol code has three buckets: cash advance, purchases, other. Hard to change

- cap1 tried to rewrite that system in c++ for distributed unix to ditch cobol and mainframes. They wanted N buckets so they could hook up with N vendors and have N incentives to build biz

- big failure ala chaos report also from 1990s. Also org dysfunction. The mainframe guys fought it much like in today's world when you have old guard fight for onprem or colo DC when somebody wants a cloud provider

- cobol won then (and I haven't been back in CC since) but not for tech reasons. In truth in abs terms cobol isn't hurt or help. There's bigger adjacent fish to consider first

This is why challenger banks are a thing, and why the big banks are starting challenger-like new banks.

Start anew without the legacy of COBOL, using tech and skills more appropriate to the present era.

Are they repeating the pattern? Maybe, but for now they get to live in the present.

Exactly: as someone who sells banking backends (in C#/.NET Core with React apps and web frontends), 'old' banks are the main clients. Note though it is not only tech that they want to rejuvenate; they make it a separate part with different people that don't have the adhere to the ancient processes (outside ISO and PCI that is) that slipped into the day to day running on the bank and is costing them money and clients. But as you say, it is also responding more rapidly to demands technically.

What is intrinsically wrong with running systems on COBOL? These systems have a very long lifetime, and COBOL has worked for that entire time.

Would it really be an improvement to rewrite a banks's backend processing software in the latest fad flavor of language and framework? We know those would become obsolete in a year.

Not everything newer than COBOL is a fad. Python or Java will still be written many years from now. Maybe not 50 years from now but some languages will not go away anytime soon.

I think Java is in group that is used in 50 years. Python might fall way of perl, php and others... Specially if there will be 4.0...

Only threat to Java is the success of the JVM, that Java could be replaced by another JVM language seamlessly, but the JVM itself will definitely be here and developed 50 years from now.

Say what you will about its merits, but PHP is used by over 75% of websites today[1]. Rumors of its demise are monumentally exaggerated.

[1] https://w3techs.com/technologies/details/pl-php

Nothing really, but I imagine a COBOL compiler (and possibly a runtime/execution environment) that still gets updated doesn't come cheap anymore. If I were writing a new banking host today I'd write it in Java or C# and be hopeful that the tech will have a longer shelf life than COBOL.

As far as I know GNU COBOL is free. At least that's what I saw when running jsfiddle for COBOL.

https://www.jdoodle.com/execute-cobol-online/

Ah right - I've never used COBOL but I thought IBM had a compiler and tools and I didn't think it would be free by any stretch.

Java won't be gone in a year: we already have Java software running for decades and I know many banks, insurers, governments do; it will be running decades from now. Too much investment into these systems.

I wonder what hardware are these running on. Are they just emulating the original architecture? Surely maintaining a mainframe from half a century ago would be at least as arcane a skillset as writing Cobol.

IBM mainframes likely offer a high level of backward compatibility, so these companies can upgrade the hardware and keep the programs more or less untouched.

Also, I wouldn't be surprised if IBM does a lot of the maintenance for you, on the hardware side.

> IBM mainframes likely offer a high level of backward compatibility

Just to add from what I’ve read. A zmachine purchased within the last several years could run in modified S/360 binaries.

In my experience supporting and administering enterprise MFT software that interfaces with these mainframes, it's largely emulated z/os.

No, COBOL is Not a Dead Language:

https://www.datacenterknowledge.com/design/no-cobol-not-dead...

I learned it around 1999 at university. Even back then they already told that myth.

But Old Code gets younger every year:

https://news.ycombinator.com/item?id=23453972

Always wanted to learn COBOL but never had an opportunity to do anything with it.

If there was an incentive, I’d do it.

Job security, apparently.

But I agree. If some big corporation is running a Cobol training program with a big paycheck at the other end, I'll sign up. But I'm not going to spend my free time training myself, I'd rather do fun stuff.

Is job security a thing that any programmer is worrying about? I'm a ruby developer and I recently sent my resume to a recruiter and had a new job 1 week later and my impression was that there were 10 other listings from this recruiter who would have hired me had I finished their interviews.

I don't have any particularly rare or specialized skills. Only 6 years ruby experience.

Would anyone know if this is a US/western specific issue?

Hard to fathom that the banking system in emerging markets would be running on Cobol or using it.

I assume it's an issue for anyone that started using computers in banking in the 1960s or 1970s (not sure when that happened around the world but it seems to be the case for Australia, USA etc).

Why is it so hard to write a translator from Cobol to a modern language? It seems there would be a lot of advantages.

It would still be spaghetti code.

The company I work for writes one (COBOL —> Java, and separately COBOL—> C++ — as well as other translators for MF tooling). It took us a …while… to reach high success rates on new customer source.

There are several issues at play:

1. The language is ridiculously verbose and inconsistent. It was designed in the era when people thought the only barrier to everyone learning programming was that it wasn’t “English” enough — so stdlib functions randomly introduce keywords for “readability”, and throw consistency out the window.

2. The mainframe tries to provide anything and everything you’ll ever need, rather than relying on user-supplied libraries, and does so by adding that functionality to the language itself (combined with above arbitrary inconsistencies). Wikipedia notes 300 keywords, and probably many more terminals in general (another reference: SQL standard apparently specifies some 1700 terminals)

3. The language is itself not well-defined, or well standardized (a standard exists, but like SQL, everyone extends it arbitrarily. And again, they extend the language, rather than supplying libraries utilizing the existing languages). There are many cobol dialects in the wild. A few major players (ibm, gcos, microfocus, and a lot of little & dead ones).

4. COBOL compiler implementors (notably IBM) have/had a habit of asking customers what they needed, and adding the feature to the compiler, intending it for the one customer. Eventually other people find it too. Undocumented unspecified statements used at random.

5. COBOL does not live on its own. It expects to run under the terms of the mainframe transaction processing and batch processing runtimes. These have to be replicated as well. Additionally database (eg DB2, Oracle), filesystem (eg VSAM), third party apps, etc. Additionally, different mainframe providers have different semantics, sometimes subtle, sometimes not.

6. COBOL does things differently than Java. I consider it a fork in the timeline of language design. Functions don’t necessarily have to return to the caller. Definition order in source code matters (eg PERFORM THRU). Weird artifacts from its punchcard history (notably 70-char limit, but also weird functions like REDEFINE). It loves fucking around with bit fields. Variables are basically global, always. Structured Control flow is really a shallow layer on top of GOTO.

7. Companies with mainframes have typically already tried & failed to get off the mainframe. By translation, or reimplementation, or emulation. They’re often cautious to try again (a problem for our sales team). Lots of companies offer to do it manually, and fail on any decent sized codebase, causing companies to be quite cautious

8. Mainframes are fast at what they do, and very reliable. It’s very much a don’t fix what ain’t broke situation. It’s also difficult to meet same performance expectations when you’re emulating the whole thing — though half the point in converting is that it’s much easier to simply throw more hardware at the problem. Conversion generally is “COBOL in Java” because safely rearchitecting it automatically to something more idiomatic is often quite difficult, or not even possible without violating unspoken assumptions; its also difficult for current maintainers to verify correctness, if you’ve mucked about with the logic flow significantly.

Aaaaaaaagh! It's not a "coding language" it's a programming language!

Are we talking about medical billing or software engineering here???

It's all entirely outdated and should be replaced by cryptocurrency.

Cryptocurrency is not a get-rich scheme, despite everyone trying to make it into that. It's just applying math and computer science to make technically sound and trustworthy modern money.

You could start your own Crypto company, get a team and then try to convince the Banks to move to your solution.

Then post on HN and let us know how that goes.

We don't need a other cryptocurrency company. That's not the point. And with cryptocurrency we don't need the banks at all.

The thing is, I want banks. I don't want a system where if someone gets ahold of a secret key all of my money is gone forever. I want a system that protects me from theft and fraud.

Right, so non-cryptographic bank account numbers and credit cards are the answer. Because someone can just change a database and pretend it didn't happen.

It's really quite a lot worse.

In theory it sounds worse, but in practice I have the impression that crypto has a much worse track record in terms of the percentage of people and currency that have been victimized by theft.

If big banks were being stolen from at the same rate as crypto exchanges, the news would be pretty Wild West.

My bank sends me cryptographically-signed bank statements. So, if they just erase my bank account by mistake, I can challenge them with the statement that they sent me earlier.

Processing transactions is probably 2% of what a bank actually does.

Reply on news.ycombinator.com