It’s not the 1st time a language/tool will be lost to the annals of the job market, eg VB6 or FoxPro. Though previously all such cases used to happen gradually, giving most people enough time to adapt to the changes.

I wonder what’s it going to be like this time now that the machine, w/ the help of humans of course, can accomplish an otherwise multi-month risky corporate project much faster? What happens to all those COBOL developer jobs?

Pray share your thoughts, esp if you’re a COBOL professional and have more context around the implication of this announcement 🙏

  • eyy@lemm.ee
    link
    fedilink
    arrow-up
    37
    ·
    1 year ago

    Not a cobol professional but i know companies that have tried (and failed) to migrate from cobol to java because of the enormously high stakes involved (usually financial).

    LLMs can speed up the process, but ultimately nobody is going to just say “yes, let’s accept all suggested changes the LLM makes”. The risk appetite of companies won’t change because of LLMs.

    • Kache@lemm.ee
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      Wonder what makes it so difficult. “Cobol to Java” doesn’t sound like an impossible task since transpilers exist. Maybe they can’t get similar performance characteristics in the auto-transpiled code?

      • qaz@lemmy.world
        link
        fedilink
        arrow-up
        16
        ·
        edit-2
        1 year ago

        COBOL programs are structured very differently from Java. For example; you can’t just declare a variable, you have to add it to the working storage section at the top of the program.

        • Kache@lemm.ee
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          1 year ago

          That example doesn’t sound particularly difficult. I’m not saying it’d be trivial, but it should be approximately as difficult as writing a compiler. Seems like the real problem is not a technical one.

          • eyy@lemm.ee
            link
            fedilink
            arrow-up
            5
            ·
            edit-2
            1 year ago

            It’s never been a technical reason, it’s the fact that most systems still running on COBOL are live, can’t be easily paused, and there’s an extremely high risk of enormous consequences for failure. Banks are a great example of this - hundreds of thousands of transactions per hour (or more), you can’t easily create a backup because even while you’re backing up more business logic and more records are being created, you can’t just tell people “hey we’re shutting off our system for 2 months, come back and get your money later”, and if you fuck up during the migration and rectify it within in hour, you would have caused hundreds/thousands of people to lose some money, and god forbid there was one unlucky SOB who tried to transfer their life savings during that one hour.

            And don’t forget the testing that needs to be done - you can’t even have an undeclared variable that somehow causes an overflow error when a user with a specific attribute deposits a specific amount of money in a specific branch code when Venus and Mars are aligned on a Tuesday.

      • DefinitelyNotAPhone [he/him]@hexbear.net
        link
        fedilink
        English
        arrow-up
        6
        arrow-down
        1
        ·
        1 year ago

        Translating it isn’t the difficult part. It’s convincing a board room full of billionaires that they should flip the switch and risk having their entire system go down for a day because somebody missed a bug in the code and then having to explain to some combination of very angry other billionaires and very angry financial regulators why they broke the economy for the day.

        • Skiptrace@lemmy.one
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Well, I’d rather the day be sooner than later. Also, this is why you have… Backup servers and development environments. You don’t just flick the Switch randomly one day after code is made. You run months and months of simulated transactions on the new code until you get an adequate amount of bugs fixed.

          There will come a time when these old COBOL machines will just straight die, and they can’t be assed to keep making new hardware for them. And the programmers will all die out too. And then your shit out of luck. I’d rather the last few remaining COBOL programmers help translate to some other long lasting language before they all kick the bucket and not after.

          • DefinitelyNotAPhone [he/him]@hexbear.net
            link
            fedilink
            English
            arrow-up
            7
            ·
            1 year ago

            Well, I’d rather the day be sooner than later.

            Agreed, but we’re not the ones making the decision. And the people who are have two options: move forward with a risky, expensive, and potentially career-ending move with no benefits other than the system being a little more maintainable, or continuing on with business-as-usual and earning massive sums of money they can use to buy a bigger yacht next year. It’s a pretty obvious decision, and the consequences will probably fall on whoever takes over after they move on or retire, so who cares about the long term consequences?

            You run months and months of simulated transactions on the new code until you get an adequate amount of bugs fixed.

            The stakes in financial services is so much higher than typical software. If some API has 0.01% downtime or errors, nobody gives a shit. If your bank drops 1 out of every 1000 transactions, people lose their life savings. Even the most stringent of testing and staging environments don’t guarantee the level of accuracy required without truly monstrous sums of money being thrown at it, which leads us back to my point above about risk vs yachts.

            There will come a time when these old COBOL machines will just straight die, and they can’t be assed to keep making new hardware for them.

            Contrary to popular belief, most mainframes are pretty new machines. IBM is basically afloat purely because giant banks and government institutions would rather just shell out a few hundred thousand every few years for a new, better Z-frame than going through the nightmare that is a migration.

            If you’re starting to think “wow, this system is doomed to collapse under its own weight and the people in charge are actively incentivized to not do anything about it,” then you’re paying attention and should probably start extending that thought process to everything else around you on a daily basis.