12 ms·

The code that controls our money

Finnucane 5y ago
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.
- porknubbins 5y ago
  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.
- tdeck 5y ago
  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-fix-it-ancient-computers-in-use-today.html https://www.pcworld.com/article/249951/if-it-aint-broke-dont...
dmitrygr 5y ago
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
- nerdponx 5y ago
  Back off! I'll do it for $750k, but only if that includes paid training.
  - tartoran 5y ago
    Sadly at only 200k/year there’d be a huge line of applicants.
    - deleted 5y ago
      [deleted]
    - civilized 5y ago
      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?
      - _tom_ 5y ago
        Does hacker need even support downvotes? I only have an upvote button.
        civilized 5y ago
        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.
        deleted 5y ago
        [deleted]
        tome 5y ago
        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 https://news.ycombinator.com/newsguidelines.html
- giomasce 5y ago
  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.
tomc1985 5y ago
Aaaaaaaagh! It's not a "coding language" it's a programming language! Are we talking about medical billing or software engineering here???
jawns 5y ago
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.
- robbedpeter 5y ago
  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.
- nerdponx 5y ago
  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.
  - Retric 5y ago
    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.
rad_gruchalski 5y ago
Always wanted to learn COBOL but never had an opportunity to do anything with it. If there was an incentive, I’d do it.
- nerdponx 5y ago
  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.
  - SilverRed 5y ago
    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.
nmstoker 5y ago
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.
- trinovantes 5y ago
  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
- wmf 5y ago
  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.
- jamesfinlayson 5y ago
  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).
6gvONxR4sf7o 5y ago
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.
- civilized 5y ago
  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
  - SilverRed 5y ago
    > 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"
    - civilized 5y ago
      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.
ilaksh 5y ago
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.
- sumedh 5y ago
  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.
  - ilaksh 5y ago
    We don't need a other cryptocurrency company. That's not the point. And with cryptocurrency we don't need the banks at all.
    - DangitBobby 5y ago
      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.
      - ilaksh 5y ago
        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.
        civilized 5y ago
        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.
jrochkind1 5y 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?
- skybrian 5y ago
  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.
- avidiax 5y ago
  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.
- civilized 5y ago
  There's probably enormous amounts of duplication there
- solresol 5y ago
  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".
jrochkind1 5y ago
> 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.
- hackcasual 5y ago
  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.
  - perl4ever 5y ago
    I never had much interest in COBOL, but I really liked Hypertalk's pseudo-english code and sometimes wish it had more influence.
    - Eliezer 5y ago
      I learned to program in hypertalk as a kid, and I am so glad that it never took off.
      - neonate 5y ago
        Why are you glad that it never took off? That's the opposite of what we usually hear from former Hypercard users...
        perl4ever 5y ago
porknubbins 5y ago
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.
- mahogany 5y ago
  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.
  - the_only_law 5y ago
    > 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.
- derac 5y ago
  In my experience supporting and administering enterprise MFT software that interfaces with these mainframes, it's largely emulated z/os.
rainpain 5y ago
>The Bank of New York Mellon in 2012 found it had 112,500 individual COBOL programs. OG microservices.
- zxcvbn4038 5y ago
  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.
aj7 5y ago
Why is it so hard to write a translator from Cobol to a modern language? It seems there would be a lot of advantages.
- wmf 5y ago
  It would still be spaghetti code.
- setr 5y ago
  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.
scrubs 5y ago
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
Nursie 5y ago
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.
- tluyben2 5y ago
  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.
IncRnd 5y ago
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.
- zaik 5y ago
  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.
  - Ekaros 5y ago
    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...
    - tored 5y ago
      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.
    - DamnInteresting 5y ago
      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 https://w3techs.com/technologies/details/pl-php
- deleted 5y ago
  [deleted]
- jamesfinlayson 5y ago
  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.
ravivyas 5y ago
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.
- jamesfinlayson 5y ago
  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).
Borrible 5y ago
No, COBOL is Not a Dead Language: https://www.datacenterknowledge.com/design/no-cobol-not-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 https://news.ycombinator.com/item?id=23453972

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.

porknubbins 5y ago
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.
tdeck 5y ago
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-fix-it-ancient-computers-in-use-today.html https://www.pcworld.com/article/249951/if-it-aint-broke-dont...

dmitrygr 5y ago

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

nerdponx 5y ago
Back off! I'll do it for $750k, but only if that includes paid training.
- tartoran 5y ago
  Sadly at only 200k/year there’d be a huge line of applicants.
  - deleted 5y ago
    [deleted]
  - civilized 5y ago
    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?
    - _tom_ 5y ago
      Does hacker need even support downvotes? I only have an upvote button.
      - civilized 5y ago
        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.
        deleted 5y ago
        [deleted]
        tome 5y ago
        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 https://news.ycombinator.com/newsguidelines.html
giomasce 5y ago
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.

tomc1985 5y ago

Aaaaaaaagh! It's not a "coding language" it's a programming language! Are we talking about medical billing or software engineering here???

jawns 5y ago

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.

robbedpeter 5y ago
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.
nerdponx 5y ago
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.
- Retric 5y ago
  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.

rad_gruchalski 5y ago

Always wanted to learn COBOL but never had an opportunity to do anything with it. If there was an incentive, I’d do it.

nerdponx 5y ago
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.
- SilverRed 5y ago
  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.

nmstoker 5y ago

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.

trinovantes 5y ago
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
wmf 5y ago
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.
jamesfinlayson 5y ago
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).

6gvONxR4sf7o 5y ago

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.

civilized 5y ago
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
- SilverRed 5y ago
  > 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"
  - civilized 5y ago
    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.

ilaksh 5y ago

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.

sumedh 5y ago
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.
- ilaksh 5y ago
  We don't need a other cryptocurrency company. That's not the point. And with cryptocurrency we don't need the banks at all.
  - DangitBobby 5y ago
    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.
    - ilaksh 5y ago
      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.
      - civilized 5y ago
        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.

jrochkind1 5y 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?

skybrian 5y ago
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.
avidiax 5y ago
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.
civilized 5y ago
There's probably enormous amounts of duplication there
solresol 5y ago
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".

jrochkind1 5y ago

> 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.

hackcasual 5y ago
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.
- perl4ever 5y ago
  I never had much interest in COBOL, but I really liked Hypertalk's pseudo-english code and sometimes wish it had more influence.
  - Eliezer 5y ago
    I learned to program in hypertalk as a kid, and I am so glad that it never took off.
    - neonate 5y ago
      Why are you glad that it never took off? That's the opposite of what we usually hear from former Hypercard users...
      - perl4ever 5y ago

porknubbins 5y ago

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.

mahogany 5y ago
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.
- the_only_law 5y ago
  > 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.
derac 5y ago
In my experience supporting and administering enterprise MFT software that interfaces with these mainframes, it's largely emulated z/os.

rainpain 5y ago

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

zxcvbn4038 5y ago
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.

aj7 5y ago

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

wmf 5y ago
It would still be spaghetti code.
setr 5y ago
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.

scrubs 5y ago

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

Nursie 5y ago

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.

tluyben2 5y ago
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.

IncRnd 5y ago

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.

zaik 5y ago
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.
- Ekaros 5y ago
  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...
  - tored 5y ago
    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.
  - DamnInteresting 5y ago
    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 https://w3techs.com/technologies/details/pl-php
deleted 5y ago
[deleted]
jamesfinlayson 5y ago
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.

ravivyas 5y ago

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.

jamesfinlayson 5y ago
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).

Borrible 5y ago

No, COBOL is Not a Dead Language: https://www.datacenterknowledge.com/design/no-cobol-not-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 https://news.ycombinator.com/item?id=23453972