62 ms·

COBOL has been “dead” for so long, my grandpa wrote about it

• Crontab 2y ago
  Do open source COBOL programs exist? Just wondering since I see it mentioned occasionally here.
• cwbriscoe 2y ago
  Started my career doing Y2K stuff in 1998 and I still touch COBOL here and there today. I have a 10,000 line CICS program that runs every 30 seconds that I wrote in 2010. It has never failed since.
  • bdjsiqoocwk 2y ago
    I don't understand these "never failed" comments. Without further context, it's meaningless. If I write a python script and never change anything in its environtment or inputs, it won't fail either. That's not specific to cobol.
    • kibibu 2y ago
      I imagine the backwards compatibility story of COBOL is a little better than Python's
    • _old_dude_ 2y ago
      COBOL changes very slowly, once in a decade or two. Python does not offer support of a release for more than 3 years and a half [1]. [1] https://en.wikipedia.org/wiki/History_of_Python https://en.wikipedia.org/wiki/History_of_Python
      • yieldcrv 2y ago
        But a compute instance or bare metal computer that never needs a new release wont have to deal with that in python either Its only new builds on someone else’s computer that have this modern issue
      • 0cf8612b2e1e 2y ago
        I could believe there are legacy installations happily humming away on Python 2.7 without issue.
        • remlov 2y ago
          Several years ago I briefly worked at a major telecommunications provider with services across the southern United States that ran Python 2.4 on their production provisioning servers. Worked just fine.
          • gavindean90 2y ago
            The difference being that the COBOL is still supported after a decade.
            • int_19h 2y ago
              ActiveState still offers a supported Python 2.7 version across all major platforms for those who need it (https://www.activestate.com/products/python/python-2-7/ https://www.activestate.com/products/python/python-2-7/), so that's 14 years and counting. If enough stuff needs it, people will keep it running. Java 8 will probably be in the same boat eventually if/when Oracle finally drops support.
              • 0cf8612b2e1e 2y ago
                I am not even sure what support is needed at this point. The interpreter is what it is. You know there are no new libraries to integrate. I guess deploying it on a newer OS which might make it challenging to install unless it is a freshly compiled build?
                • int_19h 2y ago
                  Patches for security issues, most notably.
    • ang_cire 2y ago
      If you're actually patching your python installs, that is by no means certain.
      • _w1tm 2y ago
        I don’t think those mainframes running COBOL are getting patched either.
        • ang_cire 2y ago
          They absolutely are. Modern COBOL (even 25 year old COBOL) isn't running on ancient System360/370/390s or something, it's running on modern z/OS mainframes.
          • cwbriscoe 2y ago
            Yup, Z/OS even has an AIX subsystem these days. I have had to use it for some java decryption software and to use it to do some ebcdic to ascii conversion.
        • p_l 2y ago
          They are patched up regularly. The COBOL code itself maybe not, but the runtimes?
          • cwbriscoe 2y ago
            You are correct, the OS is patched regularly but that doesn't require a recompile for the COBOL code, the OS ABI is stable and unchanging for legacy code. I have programs still running that hasn't been recompiled since 2005 (maybe earlier that is just what I noticed recently). When they upgrade hardware, they can do it per LPAR. They just shift the workloads over to other LPARS while they are upgrading another. Pretty much zero downtime.
            • p_l 2y ago
              Yep. CICS, IMS, etc. all get updates along with z/OS itself, yet I had once plugged in an user exit written and compiled before 64bit z/OS existed and it just worked.
    • tannhaeuser 2y ago
      I understand the context to be that COBOL, as a DSL for batch processing, declares its .data and .bss segments, or the equivalents on host systems, statically in the DATA DIVISION and usually doesn't dynamically allocate memory. This, coupled with CPU, memory, and I/O bandwidth reservation from a job scheduler on an exclusive hot-swappable partition on a host (z/OS aka MVS) plus USVs, redundant disks/disk ports, and networks makes "never fail" much more a consequence and primary objective of mainframe architectures where COBOL workloads are usually run.
    • Spooky23 2y ago
      If the python script has external dependencies… lol.
  • supportengineer 2y ago
    That's what I liked about developing Oracle stored procedures activated by cron jobs. Ran for 5 years, no maintenance needed.
    • lloydatkinson 2y ago
      That seems like a low barrier of expectations. I can think of several DB's that would run exactly like that.
• mbloom1915 2y ago
  almost all major financial institutions, utilities, gov't agencies, etc still rely heavily on COBOL today. If it ain't (extremely) broken, don't fix it? COBOL developers are literally dying out which has made for a competitive market for remaining talent. I've heard of some large consultants charging over $500/hr to their clients for a COBOL developer!
  • jeremyjh 2y ago
    I think the moat that COBOL developers have is not just their knowledge of the language, but knowledge of the mainframe programming and operating environment. Its just so alien to developers familiar with Windows/Linux, and there is really no way to get experience with the environment that I know of, other than to be employed doing it. But yeah that stuff is never going away as far as I can tell. Its just too risky to rewrite those core systems and many a boondoggle has tried and failed.
    • rodgerd 2y ago
      About a decade ago I looked into moving some COBOL components off-mainframe (either as COBOL-on-Linux or a rewrite into Java, which itself is really COBOL Mk II at this point), and your point about the operating environment is one of the key elements, but not all of it; there's also the fact that the first big shift to automation, via mainframe assembler and COBOL, is when companies sacked a lot of the folks who knew how and why the pre-automation processes worked - that knowledge exists in the mainframe code and the heads of the people who work(ed) on it, and nowhere else. A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree. The third is that COBOL is only the tip of the iceberg. As soon as I spent time learning about the code I was being asked to look at, you get into decades of evolving programming practises. Modern COBOL is multithreaded, probably uses DB2 and relational datamodels. COBOL from thirty years ago is probably single-threaded, only runs right on high-clocked single-execution models, cuts down to hand-written s390 assembler regularly, and uses VSAM files with non-relational data. Older code still will be sharing data simply by banging it into memory regions for other code to read out of, because that's how you got performance back in the day. Trying to identify how you'd pull a function out of that and move it off is somewhere between extremely difficult and impossible. It's usually so complicated and expensive it's easier to try and hire people who want to apprentice as mainframe programmers and keep the current codebase running.
• msla 2y ago
  "I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare COBOL is alive in that it keeps changing from era to era, to the point modern COBOL looks rather little like the 1950s COBOL everyone instinctively thinks about when they heard the term. It's as if we were still programming in Algol because Java had been called Algol-94 or something.
  • j0hnyl 2y ago
    But are these legacy systems from the 70s, 80s, 90s using modern cobol?
    • ithkuil 2y ago
      When you hear about people being paid $X vs 10x$X to fix some cobol; is there a correlation between the age of the cobol system?
      • HeyLaughingBoy 2y ago
        Probably not; just a matter of how desperate they are.
        • ithkuil 2y ago
          Which is also a function of how hard it is to find someone who has the required skills to address the problem
    • jcranmer 2y ago
      Almost certainly yes. The "legacy systems" are likely running on versions of the mainframe with long-term support contracts, whose vendors are committed to providing newer compilers with support for newer versions of the specification as necessary.
    • NikolaNovak 2y ago
      Depends what you mean; but not necessarily. I am managing an ERP system implemented / went live in 2016. It's working on modern P10 hardware, which was released in 2021. The ERP system is continually updated by the vendor and customized by the client. Even for COBOL running on an actual mainframe, which I think most HNers would think of 1970s dinosaur, most of the actual machines in production would be pretty new. IBM z16 was launched in 2022. So they are "legacy systems" in the sense they're not written on a javascript framework which was launched last week, running on lambda instances in AWS :). But they are not "OLD" systems, as such.
• mckn1ght 2y ago
  Huh, so it mentions 4GLs… what generation would we consider rust/kotlin/swift then?
  • stonethrowaway 2y ago
    They haven’t been around long enough to even be considered in the running.
    • adamc 2y ago
      4GL was really more a marketing slogan than a true generation. The idea was something like "with third generation tools, you have to drive the car, making every turn yourself, with 4th Gen., you say "Go to the Ritz!". It wasn't true, although they did make some operations easier in tangible ways. Rust is a wholly different kind of thing -- not easier than, say, Java, but lots more control with better guarantees. It's more a systems programming language. 4GLs were all application-focused.
  • skavi 2y ago
    third generation: https://en.wikipedia.org/wiki/Third-generation_programming_language https://en.wikipedia.org/wiki/Third-generation_programming_l...
  • rodgerd 2y ago
    The modern analogue of 4GLs would be the promise of LLMs letting you write prompts so you don't have to learn a programming language; the promise of the original 4GLs like Pearl (not to be confused with perl) and Objectstar was to let you have non-programmers writing business logic without being COBOL or FORTRAN programmers.
    • psunavy03 2y ago
      Ironically, the whole reason COBOL has its weird-ass syntax was to let you have non-programmers writing business logic without being assembly or C programmers. We can see how well that worked.
• adamc 2y ago
  Technologies die very slowly once things of economic value depend on them. COBOL probably isn't used from new projects very often, but the economics of ditching it aren't very good either. It already works. Rewriting things that work is a great way to create new problems at great expense, so institutions are hesitant.
• throw0101b 2y ago
  Bloomberg's Odd Lots podcast had an episode last year, "This Is What Happens When Governments Build Software": * https://www.youtube.com/watch?v=nMtOv6DFn1U https://www.youtube.com/watch?v=nMtOv6DFn1U One reason COBOL systems have been around for so long is because they encoded business rules that need to be understood if you want to try to transfer them to a new system. From the podcast (~16m): > Like when we're working in unemployment insurance, again during the pandemic, my colleague was talking with the claims processors week over week and we're trying to dissect it and figure out what's going wrong and clear this backlog and one of these guys keeps saying, “Well, I'm not quite sure about that answer. I'm the new guy. I'm the new guy.” And she finally says, “How long have you been here?” And he says, “I've been here 17 years. The guys who really know how this works have been here 25 years or more.” > So think about. You know, going from doing some simple cool, you know, tech app, you know, easy consumer app to trying to build or fix or improve upon a system that is so complex that it takes 25 years to learn how to process a claim. > That's sort of, I think, what needs to be on the table as part of this agenda is not just “can the tech be better?” But can we go back and simplify the accumulated like 90 years of policy and process that's making that so hard to make? Also an observation on how decisions are sometimes made: > And I think that there's a deep seated culture in government where the policy people are the important people. They do the important stuff and technology, digital is just part of implementation, which is not just the bottom of a software development waterfall. It's the bottom of a big rigid hierarchy in which information and power and insights only flows from the top to the bottom. > And so it's problematic in part because the people who are doing the tech are really just sort of downstream of everything else and the power and ability and willingness to step up and say “Hey, we probably shouldn't do those 6,700 requirements, we should probably focus on these 200, get that out the door and then, you know, add edge cases as as later.” There's no permission really to say that.
  • shadowgovt 2y ago
    > ...add edge cases as as later.” There's no permission really to say that. I think there would be some value to closing that feedback loop to give legislators the signal "You know, what you're considering is actually pretty fuzzy conceptually... We're discovering while considering how to code it up that you probably don't actually have good, clear definitions for all the terms in this bill." But the biggest thing to remember about government IT is the clientele, which changes the approach from commercial / industry software. Google can optimize for the common case. Google can cut the edge cases. Google can change APIs on a whim. Google's users choose to be Google's users and can go elsewhere if they don't like it. Government citizens don't have that choice. And in general, people don't lose access to their food if Google effs up. Or go without their legally-deserved unemployment pay. Or go to jail because their taxes were mis-calculated. In the government space, the "edge cases" are human beings, alike in dignity. The rules and policies end up complicated because human beings are complicated. And yeah, it ends up being some messy software. Because you can't just decide to ignore the law when it's inconvenient to plumb the information that the client has a child under the age of 18 who is not a dependent because they're an emancipated minor, but said emancipated minor does have a child of their own, and the client is the primary caregiver for that child while her parent is in prison... from here to there in the dataset.
• tombert 2y ago
  You know, one of these days I really need to sit down and play with some of these "legacy" languages, like Fortran or COBOL or Ada or APL; languages that have certainly fallen out of popularity but are still used in some critical places. It does make me wonder about millions and millions of lines of Java out there; Java has more or less eaten the enterprise space (for better or worse), but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems?
  • fastneutron 2y ago
    Fortran is alive and well in science and engineering. The more modern standards are much nicer to work with, but largely backwards compatible with stuff written 50 years ago.
  • adastra22 2y ago
    Fortran is not a legacy language.
  • Suppafly 2y ago
    >but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems? It feels like we're getting into that space already.
    • Muromec 2y ago
      Nah not really. People just started replacing COBOL with java and employers are wise enough to hire people who are 30-40 years minimum from retirement. It can also be upgraded in smaller chunks and finding enough developers for the tool is an important metric corporate is looking at. If anything, banks are actively optimizing for developer experience to make sure 60% of new hires don’t run away in the first year. If anything, banks are better at navigating those kind of structural risks, they were just slow on undertaking such risks exist. If you have an episode of existential anxiety because of dat AI eating mijn job, getting a union job in a bank is a way to hedge this particular risk.
• norir 2y ago
  I think of scala in this context. I think that scala is basically dead at this point in the way that COBOL was framed in the article. Yes, there are still many businesses/services that have critical components written in scala but current mindshare has cratered for new projects. I only single out scala because I have spent a lot of time with it and have seen it go through the hype cycle (in 2012-14 it seemed like I was constantly seeing doing $X in scala pieces on HN and I almost never see it referenced here anymore). It's probably a natural and inevitable phenomenon (and a bit of a shame because scala did get some things right that other mainstream languages still have not).
  • empathy_m 2y ago
    Does Twitter still have software in Scala?
    • winrid 2y ago
      Yes https://github.com/twitter https://github.com/twitter
  • 7thaccount 2y ago
    I assume it became less popular when Java became more bearable.
    • n_plus_1_acc 2y ago
      And kotlin came around with great IDE support, and with good features without the complexity of scals
      • lol768 2y ago
        It's hard to understate how much better the Kotlin IDE support is vs Scala. In terms of reliability the Scala IntelliJ plugin really seemed to go downhill for me with Scala 3, which was a real shame.
    • paulddraper 2y ago
• WaitWaitWha 2y ago
  (Programming) languages take very long to "die". Most often you will get a long drawn out tail, and often parts of a language gets absorbed into other languages. Only the sages and etymologists will know where they have come from. Old man reminiscence following, skip if you are not bored: I worked with SNOBOL and I thought it will be a long term programming language. I also want to think that I had some tiny, minuscule hand in dev of RIPscrip pre-Telegraphix, alas it went as the dodo bird. I think I have forgotten more programming languages than I can count on my hands. Yet, I see them in some part every day in newer languages, "discovered" by some expert. "What has been will be again, what has been done will be done again; there is nothing new under the sun." One language has come to my aid for the last 30-ish years Perl has came to my aid many times. (I tell you a secret - in the deep deep bowels of a a very, very large, jungle named company, servers still have tiny Perl scripts running some core functions. I discovered this, when there was a problem that I had to deep dive into. I a recommendation to change to a hard-coded variable. The answer was "it will take two weeks". Why? Because no one knew what it will do or could read Perl. It was a 30 second job, including sdlc. Think xkcd Dependency https://xkcd.com/2347/ https://xkcd.com/2347/ )
• snovymgodym 2y ago
  As always, these discussions will depend on your definition of "dead" and "alive". If we can call a technology dead once no new business is built on it, then I think we can safely call COBOL dead (and the IBM 390x aka Z/OS platform along with it, for which "COBOL" is usually a proxy). But if we say that anything still being used in production is not dead, then of course COBOL is alive and significantly more alive than many other things which are younger than it. But this shouldn't really be taken as a positive point for COBOL or the mainframe ecosystem. It's simply a fact of life that organizations tend to stick with the first thing that works, and for the types of entities involved in the first wave of digitalization (e.g. governments, banks, airlines) that was usually an IBM mainframe along with the software that runs on it.
  • DaiPlusPlus 2y ago
    > we can call a technology dead once no new business is built on it You don’t suppose any bank - or other large financial institution - might have standardised on Cobol for their core business flows/processes? In which case a new business-unit or “internal startup” team (e.g. a new category of insurance product) might very-well have some part written in Cobol so it integrates with the rest of the bank - or at very-least might be built-on-top of the org’s existing Cobol-running infrastructure (i.e. Not written in Cobol, but still runs on Z/OS because there’s no budget for buying new commodity x86 racks and the people to manage and run them).
    • snovymgodym 2y ago
      Sure, I know for a fact that what you're describing exists. That's not really what I mean by new business being built on it. That's a case of a very large and old business already being so locked into the mainframe ecosystem for their core systems that anything new they try to do ends up needing some kind of integration system with the legacy system. What I mean is that nobody starts a business today and says "Ok, we need an IBM mainframe running DB2 and we'll have a bunch of COBOL, ReXX, and PL/I programs for handling our business logic".
      • zifpanachr23 2y ago
• blastonico 2y ago
  Soon after Java was released, when the hype around the language was on fire, people used to say that it was going to replace COBOL - due to the "build once run everywhere" motto. Java indeed gained market share in the finance industry, but COBOL is still there.
  • cies 2y ago
    Java is much bigger though in that space. Java's relative market share in the finance industry %LOC is waaaay bigger than COBOL's.
• FrustratedMonky 2y ago
  Is PERL dead yet?
  • adastra22 2y ago
    PERL is undead.
  • hardburn 2y ago
    No
  • cies 2y ago
    I asked ChatGPT -- Please estimate the popularity of these languages, relative to the most popular one (that gets 100%). Base your answer on community activity on different platforms (stackoverflow, reddit, hacker news, dev.to, github) and the number of books available and sold: COBOL, Perl, PHP, BASIC, TCL, ColdFusion. Estimated popularity: PHP: 100% (reference) Perl: 30% COBOL: 25% BASIC: 10% TCL: 8% ColdFusion: 5% (I consider all of these dead, or, "in maintenance mode")
    • rafark 2y ago
      Why php though? Php is as old as java and very popular and constantly updated.
      • cies 2y ago
        we need a reference... and PHP is the biggest language that has clearly better options available in it's space. JS is not too pretty either, but I understand many believe it's the only lang the browser understands.
• brightball 2y ago
  For what it's worth, I'm still actively looking for a COBOL speaker for the 2025 Carolina Code Conference. Been wanting to get a COBOL talk for a while, especially with GnuCOBOL's recent update. https://gnucobol.sourceforge.io/ https://gnucobol.sourceforge.io/ https://carolina.codes https://carolina.codes
  • jklowden 2y ago
    www.cobolworx.com. Always on the lookout for places to talk about our work.
• deenadz 2y ago
  COBOL is dead, long live COBOL. For any cobol devs here, we at https://cobolcopilot.com https://cobolcopilot.com would love to hear from you
  • Muromec 2y ago
    You need to sell on-prem to those people. No way a single byte of that sweet sweet poison is going to ever leave the corporate network boundary.
• flatpepsi17 2y ago
  Article starts mentioning 4GL's - a term I have not heard in a long, long time. COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code. The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. When you get down to breaking down that problem... you become a programmer. The main lesson of COBOL is that it isn't the computer interface/language that necessitates a programmer.
  • cwbriscoe 2y ago
    4GL's were a mistake. We have 4gl code that was compiled into COBOL. Nice. Except, nobody still around knows the 4gl language and the generated COBOL is completely unreadable.
  • _yb2s 2y ago
    > we wouldn't need programmers anymore This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages. But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper, and have it work - something few people can or need to do nowadays
    • AdieuToLogic 2y ago
      > This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages. I have heard others and myself describe COBOL in many ways, most involving creative expletive phraseology which would make a sailor blush, but "low level/terse language" is a new one to me. > But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper ... LISP and Fortran predate COBOL IIRC.
      • andsoitis 2y ago
        > LISP and Fortran predate COBOL IIRC. Correct. Fortran, LISP, and COBOL were invented in ‘57, ‘58, and ‘59, respectively.
• palisade 2y ago
  Note: I'm getting some hate from others who think I would pick or prefer COBOL over a modern language. I wouldn't. I was making an outside-the-box "devil's advocate" objective observation. I just wanted to preface that here. Okay, the rest of my original comment remains below: The irony is that we already had a memory safe and stable language in Cobol that was easier to read and understand than Rust. But, no one wants to use it so it is "dead" but it runs everything that made the modern age possible. RUST: println!("Enter number: "); let mut input_string = String::new(); io::stdin().read_line(&mut input_string).unwrap(); let number: i32 = input_string.trim().parse().expect("Please enter a valid number."); let result = if number % 2 == 0 { "EVEN" } else { "ODD" }; println!("The number: {}", result); COBOL: display 'Enter number: ' accept number if function mod(number,2) = 0 move 'even' to result else move 'odd' to result end-if display 'The number: ',result
  • sestep 2y ago
    This is a weird take. Sure, plenty of cool/nice things from old languages (e.g. variable-sized stack frames in Ada) get lost, and some then get rediscovered by future languages, potentially wasting effort. And I don't know COBOL, so maybe you're actually making a good point. But I find that hard to believe. Does COBOL really solve all the same problems Rust is intended to solve? Is it as performant? Can it interface with native code from other languages in the same way? Does it have a usable and sane package manager built on top of a module system that facilitates composability and backward compatibility? Does it have a way to describe the shape of data and errors as ergonomically as Rust's algebraic data types? Genuinely curious: as I said, I don't know COBOL. I'd find it extremely surprising if the answers to all these questions are "yes," though. Just as there are reasons COBOL is still used, there are also (good) reasons new languages have been created.
    • Muromec 2y ago
      Imagine having a shell script being called from a cron job that writes data in a bunch of tab separated memory mapped files (memory mapping happens when you configure the thing), but you have more files than memory. And all the shell scripts call and include each other and have global variables too. And that underpins most of the critical infrastructure in your country.
• happyjim 2y ago
  Key components of the U.S. Internal Revenue Service tax processing code (e.g., the "Individual Master File" or IMF) are written in COBOL and IBM Assembly Language. There is an ongoing effort to refactor as Java. This will ultimately take years and cost $100s of millions of dollars. There is still a small but shrinking team of graybeards who can actually maintain the code, which has to be reprogrammed every year to accommodate changes to tax code. See, e.g., IRS IT Strategic Plan documents, publicly available.
• kayo_20211030 2y ago
  Great story. There's something wicked personal in it, and it's very good. I reckon that this bloke's grandfather was an interesting bloke - cobol or no.
• sshine 2y ago
  I know someone my age (mid-late 30s) who is a COBOL programmer for a bank. He's been that for ~5 years. I don't think it's going away any time soon.
• gpraghu 2y ago
  A touching article! I have enjoyed similar times with my grandpa. On the topic of Cobol, I simply don't understand why people hate it so much. It has a shallow learning curve like Python, is self-documenting enough that one doesn't need to write a bunch of text, and is available on every conceivable architecture, with great performance. I personally wrote a payroll for an entire factory on a B1800 with 128K of memory and a 10MB hard disk! So what's to complain? In my mind, Java is deader than Cobol!
  • ape4 2y ago
    Its the amount of boiler plate that people hate.
    • acdha 2y ago
      I think there’s something to that but there’s also a lot of selectivity there. Many of the same people who complained about COBOL because it was verbose adopted things like enterprise Java, so there’s more than a suggestion that this might be a less than completely objective assessment. The bigger problem: COBOL was an open standard but none of the implementations were open source for ages (I haven’t looked at GNU COBOL in years, but I think this is no longer the case) so nobody was building new things or experience when they had to pay to get started.
• socketcluster 2y ago
  It's interesting reading articles from previous generations how they make it sound like people seem to remember what everyone in the tech industry said as if everyone mattered. I guess there weren't many people around in the industry back then. Nowadays, even if someone is right about something and most people are doing it wrong, nobody will care to even discuss it unless the person making the statement is one of maybe 3 top influencers in that field.
• deleted 2y ago
  [deleted]
• LarsDu88 2y ago
  As long as there are tactical nukes that depend on COBOL, COBOL ain't dead. We might all die, but COBOL will sit happy in its steel reinforce nuclear bunker
  • diggan 2y ago
    Still doesn't beat Assembly, which will continue running on Voyager 1 even after the inevitable demise of our planet. Would survive the end of our solar system too.
    • LarsDu88 2y ago
      Assembly ain't a language. Differs for every chip microarchitecture. Doubt there's many folks who know voyager 1 assembly
      • criddell 2y ago
        Assembly is a language. It’s human readable, not machine readable. Modern assemblers support all kinds of higher level constructs through macros.
      • TheSkyHasEyes 2y ago
        > Assembly ain't a language. Differs for every chip microarchitecture. Your last sentence explains why ASM is a language. ASM compiles to machine language.
• MarkusWandel 2y ago
  Frankly, in all these stories about COBOL programs being modified for Y2K and whatever... isn't COBOL a compiled language? What's really amazing is that all these legacy systems have buildable source code and the toolchain to build them with i.e. that that stuff hasn't suffered "bit rot" or other neglect.
• yawnxyz 2y ago
  huh so are any languages actually dead? ChatGPT mentions FORTRAN, ALGOL, or Pascal... which I don't think are dead at all. Ada I've never heard of, so maybe that one's dead? If they're able to write WebAssembly compilers for all these languages, then they'll probably live forever! The only reason punchcards are "dead" is bc the machines are gone or mostly unavailable...
  • marcolussetti 2y ago
    Ada is still updated, last released in 2023. Given its original audience is the Department of Defense, it seems to me very likely it is far from dead.
  • atrettel 2y ago
    Fortran is very much not dead. https://fortran-lang.org/ https://fortran-lang.org/
    • pklausler 2y ago
      Fortran’s doing fine, but that discourse is not very useful.
  • int_19h 2y ago
    It depends on how you define "dead". ALGOL proper has been dead for many decades, but pretty much all mainstream general purpose PLs today are its direct descendants, and sometimes this ancestry is plain to see (e.g. every time you write "struct" or "void" in a C-like language, that's straight from ALGOL 68). I once wrote a comment on HN summarizing all the various bits and pieces I know of that are still around: https://news.ycombinator.com/item?id=18691821 https://news.ycombinator.com/item?id=18691821
• mcv 2y ago
  Just this week a colleague asked if someone knew Cobol. Apparently another team had a Cobol-related issue. So despite its long death, it still seems to be kicking about. I doubt we'll ever get rid of it.
• facorreia 2y ago
  I worked for a company in the late 1980s that started developing with a 4GL product (Dataflex) instead of COBOL. The article is right that COBOL has outlasted most (all?) of those 4GL solutions. Looking back, COBOL would have been a better technical choice back then. Dataflex's metadata-based dynamic UI and report generation saved some simple, repetitive work, but much more effort was wasted working around its limitations.
• markm248 2y ago
  https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
• Frummy 2y ago
  It's tragicomical, since it's at the core of renowned institutions I thought surely this must be a world of logical, crisp perfection. A perfectly engineered engine, surely if these systems are so important and at the very center of what makes society work and all flow of money and whatever, geniuses must have perfected it all thrice-over. I wouldn't say reality was equal to 1/expectations^3 , but maybe 1/expectations^2. Probably no one will relate, a COBOL job was the first developer job of a relatively young guy like me. Crash course in tech-debt, decades worth of managerial shortsighted behavior, bureaucracy and all that. At least the naive hope provided energy to learn it better so it wasn't useless. But maybe it veered on delusion when I hoped to rewrite ALL of it in the company I was.
• sys_64738 2y ago
  I recently found a 3.5” disk image I had with my 1990 COBOL programs on it.
  • iefbr14 2y ago
    You are lucky. I started in '75 and my first cobol programs were on punch cards. Maybe some bits are still going round in napkins and toilet paper..
• HackerQED 2y ago
  RIP. He is an old man with wisdom and a sense of humor.
• ryukoposting 2y ago
  When I was in college, I knew a guy who got an internship at Wells Fargo writing COBOL. He hated it. The punchline is that this was in 2018.
• kukkeliskuu 2y ago
  Cloud is the new mainframe, except worse. It has all the downsides, but does not have the biggest upside. The grandpa could create (using CICS), a very reliable and performant service that would call other services inside the same transaction. The platform would handle all the complicated stuff, such as maintaining data integrity. Try to write AWS Lambdas that call each other within the same transaction.
  • sofixa 2y ago
    > It has all the downsides Vendor lock-in from a single vendor? Wildly expensive capex and opex? Impossibility for people to know any of the tech involved without you sending them on a course to learn about it or them already having experience with it? > Try to write AWS Lambdas that call each other within the same transaction. Why is that your comparison? Was deploying to the mainframe as simple as throwing a .zip with your code at an API that you could give access to developers?
    • otabdeveloper4 2y ago
      > Vendor lock-in from a single vendor? Wildly expensive capex and opex? Impossibility for people to know any of the tech involved without you sending them on a course to learn about it or them already having experience with it? Is this a trick question? The answer is 'yes' to all three.
      • sofixa 2y ago
        For mainframes, it is. For AWS, it isn't. Outside of a few narrow exceptions, there is no vendor lock-in into a single vendor. (A container that can run into Lambda can run into Google Cloud Run just fine). There is no capex with AWS. There's a free tier and it's freely accessible to anyone. Anyone, and I mean anyone, can start learning it if they want to. Good luck getting access to a mainframe to play around to see how and what works. Or finding any useful tutorials from this century.
        • kukkeliskuu 2y ago
• bigiain 2y ago
  This makes me feel old. In '92 I was maintaining COBOL code for a custom written warehouse management system for a wholesale boat bits distributor. The company that wrote it had lost almost all their COBOL devs, and were all in on Windows NT application dev. I hate to admit it to myself, but I am in fact _just_ old enough that I could have cs grad aged grandkids, if I'd had kids early and they'd also had kids early. :sigh:
• solatic 2y ago
  COBOL is endangered, even for banks and airlines. Just look at the executives who see decide to open new digital banks - they're not building on top of COBOL or mainframes. The old banks will be outmaneuvered by the new ones, and eventually succeed them in the market. The story of languages like COBOL isn't that a language is too deeply embedded to become too expensive to replace. It just means the replacement will happen at a higher level - the business itself, and will take more time as a result.
  • nasmorn 2y ago
    A single cobol mainframe application is not a problem for a bank. Big banks are usually made by buying up dozens of other banks so they might have very many of these mainframes running and interoperating. That is where the real insanity lies
• martinclayton 2y ago
  In case anyone is interested... The SO Developer Surveys give some info on the job market for COBOL as it appears on the average salary versus years-of-experience graphs, which I like as there's as many stories or reasons as you can think of to explain them. In 2023 there were 222 respondents who averaged 19 years of experience, and an average salary of $75,500. In 2024 the exact number of respondents is not shown, but likely similar based on the color code of the point, but the average experience had dropped to 17 years. Elsewhere in the graph my favourite open question is: how come the over 2000 respondents mentioning Swift average over 11 years experience in a language that's only been public for 10 years? 2024 https://survey.stackoverflow.co/2024/work#salary-comp-total-years-code-pro-language https://survey.stackoverflow.co/2024/work#salary-comp-total-... 2023 https://survey.stackoverflow.co/2023/?utm_source=so-owned&utm_medium=blog&utm_campaign=dev-survey-results-2023&utm_content=survey-results#section-salary-salary-and-experience-by-language https://survey.stackoverflow.co/2023/?utm_source=so-owned&ut...
  • clarle 2y ago
    iOS development has been around for quite some time now. Most senior iOS and Cocoa developers probably started with Objective-C before slowly migrating codebases over to Swift.
    • martinclayton 2y ago
      I think this must be it, or at least this is one story that fits. Seems a shame that people report Objective-C experience as Swift experience to such a great extent. These surveys are not resumes... Perhaps it just "proves" that all data in these charts is questionable.
• FLT8 2y ago
  20 years ago I worked on a mainframe system that, at the time, was said to have "18 months to live". Fast forward to today, the system is more entrenched than it ever was, and still has "18 months to live".. I'm convinced it will outlive me, and probably the next generation too.
• nrollinson 2y ago
  COBOL's gone? Time to tell grandpa his coding skills are officially retro chic.
• masfoobar 2y ago
  condolences to the writer on his grandads passing. It is a bit of a reality check when words like 'grandpa' are linked to an article from 1992! My brain is expecting the article to be from the 60's, 70's... or possibly 80's. My world view, it is hard to image a child born in 2000 is 24 years old now. Their grandparents could be as old as I if they had children (and their children) at a young age. Then I read at the end he was 91 when he passed. He did well! Likely around my Grandads age - and managed to last an extra 24 years on this planet! I remember reading a book on COBOL in my younger days learning to program, alongside BASIC, C, and Pascal. I might still have it. Despite reading and never coding in it, I have been (fortunate, I guess) to have never programmed in it. I do agree with the writer that using the word "dead" in the programming language world is unrealistic. Some would argue that there are popular, modern languages out there as being "dead" - but they might get a huge push for one reason or another in the future. Could COBOL find a new, niche spot. Maybe.
• zerop 2y ago
  Cobol is dead, really? Read comments and main article - "The code that controls our money" -- https://news.ycombinator.com/item?id=28458300 https://news.ycombinator.com/item?id=28458300
• lasermike026 2y ago
  With LLMs which programming language used becomes irrelevant. LLMs do not replace programmers yet but they do give programmers incredible leverage making these points moot.
• ttepasse 2y ago
  Tangentially, I love this tweet: https://x.com/grauhut/status/1000017084435312642 https://x.com/grauhut/status/1000017084435312642 Translated: > "I found some COBOL at a customer site. Fine. Mainframe. Nothing special. > The last comment is from 1985. > Written by my mother."
• lefessan 2y ago
  COBOL is not dead, but it's difficult to get access to, because there is almost no open-source tooling around it for Linux. We (OCamlPro) have created a project, called SuperBOL, to create an open-source environment around the GnuCOBOL open-source compiler (that is now very mature and used by companies). We have already released the VScode extension with an LSP for COBOL to get a modern IDE, and we are working on other tools, mostly depending on our customers.
  • kwanbix 2y ago
    The problem is not so much access to tooling, but access to mainframes. I can learn COBOL in a day or two, and I would love to work on a "boring" COBOL job, but I have no experience with mainframes.
    • imgabe 2y ago
      Is there anything particularly different about mainframes compared to working on a server besides it probably being a different operating system? I assume it has a command line and you ssh into it somehow (or something similar)? Or are they still running punch cards or something?
      • julian_t 2y ago
        It's a very different (and foreign) environment. Job control language, how data is stored... if you come from a typical modern server environment you'd be pretty lost in the mainframe world.
        • macintux 2y ago
          In 1996 I took a TCP class in Chicago for which it turned out I was overqualified; it was mainly how to use tools like telnet and FTP. But what I remember most: the two other students were mainframe programmers, and they were just as baffled by my world as I was by theirs. It really was an entirely different computing paradigm, although 30 years later I probably have enough experience to make more connections than I could then.
• palisade 2y ago
  Oh, btw, COBOL has the 2038 problem and it is right around the corner. We're going to need A LOT of new COBOL engineers to fix it. It runs so much of our world. We managed to save the world from Y2K in the nick of time. But, I'm not sure if we're going to have the minds necessary to solve 2038 by then as the can has just been kicked down the road without consideration. If anyone is worried there won't be jobs, there WILL be jobs. Not to be too macabre, but we need to transfer the knowledge while the people who have it are still alive, can remember and can teach others to pick up the torch. And, let us call it was it is, of those remain and still have the desire to make the effort to transfer that knowledge. It is easy to look back on y2k and think well that wasn't a big deal, but the only reason it wasn't is because people tirelessly worked to stop it. It is a testament to their success. Regarding y2k Robert Bemer tried to warn people in 1971, with 29 years left to go. And, Peter de Jager published his attention-getting article "Doomsday 2000," in 1993 (in Computerworld), with a mere 7 years left which finally put the fire under everyone's ass. Keep in mind, there were still many original COBOL programmers and mainframe experts left to talk to at that time. And, there was a lot less code to change back then than there is now. Voting tabulation, insurance, utilities, administrative systems, banking, ATMs, travel, healthcare, social security, point of sale, IRS, pension funds, TACTICAL NUKES, hotel bookings and payroll programs. More than 800 billion lines of COBOL code in production systems in daily use. For better or worse, it is the very bedrock of our modern society. If you want to replace it with something that you want to maintain instead, that's fine too but we're running out of time. "Danger, Will Robinson! DANGER!" https://www.youtube.com/watch?v=OWwOJlOI1nU https://www.youtube.com/watch?v=OWwOJlOI1nU "Listen the nothing will be here any minute. I will just sit here and let it take me away too. They look... like... big... strong hands.... Don't they?" https://youtu.be/symP4QT7wLU?feature=shared&t=24 https://youtu.be/symP4QT7wLU?feature=shared&t=24
  • palisade 2y ago
    Forgot to mention the post office. And, there are probably many more.
  • coldpie 2y ago
    This sounds interesting, but I wonder who this message needs to be directed to? As a dev who doesn't work there, I can't just go "fix 2038 for the post office." Are you encouraging devs like me to go try to get themselves hired into these positions now, and advocate allocating resources to fix these problems? Are you trying to tell the higher-ups at these places about a problem they might not know about?
• HPsquared 2y ago
  Scientists still use Greek, lawyers still use Latin.
  • anthk 2y ago
    Romance language users will use both at the same time to create new terms.
    • HPsquared 2y ago
      I guess those ancient languages still live on through a lot of modern languages. Unlike COBOL which is more of an offshoot.
• rogerian 2y ago
  I think many would dispute that its dead. Apparently more than 95% of ATM swipes and 43% of banking systems are written in COBOL. No idea how true that is.
• dev1ycan 2y ago
  COBOL programmers spreading fake rumors about COBOL being dead so they keep their $200k-300k salaries
• eddieroger 2y ago
  I'm very late to this post, so I'm sure this will get lost, but in case OP sees it, I'm very sorry for the loss of your grandparents, and hope that you found some joy and comfort in writing about your grandfather fondly in this article, and he has found peace after the loss of your grandmother.
  • hardburn 2y ago
    Thank you!
• martabarus1 2y ago
  [dead]
• bitwize 2y ago
  I find it fascinating that the recommended environment for IBM mainframe COBOL development is... Visual Studio Code. IBM makes a plugin that lets you remotely edit COBOL code on the mainframe in your editor. Guess COBOL is alive enough to warrant this kind of support.
  • zifpanachr23 2y ago
    Works for Assembly and JCL and REXX as well, and if you don't mind turning off some of your local LSP support like header resolution and the like, also C/C++ and Java and Shell. The old guard mostly still prefers ISPF though cause they've become really fast in it not unlike a Unix greybeard is gonna prefer something like vim. I'm sorta torn on it. I like using the 3270 environment cause I can get around to different places a little easier than via vscode, but if I'm editing a lot of large files, it's nice to be able to see more code at once and have them open in multiple side by side tabs. You can do that in ISPF, but it's a little more unwieldy and you have less dynamic control over font size.
• timvdalen 2y ago
  > such as fourth-generation programming language (4GL). If you’re not familiar with that term, suffice it to say that the Wikipedia page lists several examples, and Cobol has outlasted most of them. I'll have you know I was approached for a FileMaker project not too long ago!
  • calvinmorrison 2y ago
    cries in maintaining our entire business backend in Aestiva HTML/OS
• jtotheh 2y ago
  I worked for a while as a contractor for the US Dept. of Education Student Loan system. It was z/OS with DB2 and most new business logic was done in this weird language "Gen" https://www.broadcom.com/products/mainframe/application-development/gen https://www.broadcom.com/products/mainframe/application-deve... . Gen can supposedly "generate" java and other stuff but they used it to generate COBOL for the mainframe. You could debug the Gen code on the 3270 emulator, rather than trying to deal with the generated COBOL. There were a small number of people (like 6) who were handling that code. The data and I guess some of the code went back to like 1980 at least. There was so much legacy code, I doubt they've changed platforms. I was supposed to be more a Java guy but I did a little Gen. Mainframe is very alien to me. The people that knew it well could really crank on it, though. I joined when they were converting an MS ASP front end to a Java one. So we wrote Java that users interacted with via the web and that made calls to Gen (really, to cobol). In retrospect there was a lot wrong with that operation... One interesting problem that came up once was that the mainframe didn't sort things the same as Java. It turned to be caused by EBCDIC vs UTF.
  • sigmonsays 2y ago
    thanks for sharing that, it's super entertaining to consider what crazy things people might be doing in the future. Debugging EBCDIC was a surprise and got me laughing.
• krackout 2y ago
  COBOL is dead? Not at all. Are new projects created in COBOL? Yes they do. If not in older COBOL form, definitely in SAP ABAP. For those who haven't heard about it, ABAP (Advanced Business Application Programming) is the name of SAP’s proprietary, fourth-generation programming language :) It's SAP's main language. It's a direct descendant of COBOL, I'd describe it as a COBOL with OOP extensions. Since SAP's ecosystem is sneaking everywhere, COBOL in its modern, very close incarnation (ABAP), gains new space! If in any doubts, check some ABAP code. It's not simply influenced by COBOL, it's COBOL.
• pnw 2y ago
  My first job was programming an ancient COBOL system in a government agency riddled with outdated tech. The only real upside was, COBOL is so wordy, it forced me to improve my typing speed!
• xiande04 2y ago
  I read The Cuckoo's Egg by Clifford Stoll (highly recommend btw) published in 1989. I laughed out loud when he described Cobol as an antiquated language that no one wanted to support. In 1989.
• DrPimienta 2y ago
  So is it worth learning COBOL for someone just looking to make money or not? I've heard people say yes, you can make a lot of money being the code monkey to fix the governments' software, and no, learning COBOL will not be enough (you need specific insight to whatever you're fixing as well).