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 🙏

  • LeylaLove [she/her, love/loves]@hexbear.net
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    This is what in thinking. Even the few people I know IRL that know COBOL from their starting days say it’s a giant pain in the ass as a language. It’s not like it’s really gonna cost all that much time to do compared to paying labor to rewrite it from the base, even if they don’t end up using it. Sure, correcting bad code can take a lot of time to do manually. But important code being in COBOL is a ticking time bomb, they gotta do something.

      • FaceDeer@kbin.social
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        edit-2
        1 year ago

        Counter counterpoint: The longer you let it sit the more obsolete the language becomes and the harder it becomes to fix it when something does break.

        This is essentially preventative maintenance.

        • gravitas_deficiency@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          Counter^3 point: a system that was thoroughly engineered and tested a long time ago, and that still fulfills all the technical requirements that the system must meet will simply not spontaneously break.

          Analogously: this would be like using an ML + LLM to rewrite the entire Linux kernel in Rust. While an (arguably) admirable goal, doing that in one fell swoop would be categorically rejected by the Linux community, to the extent that if some group of people somehow unilaterally just merged that work, the rest of the Linux kernel dev community would almost certainly trigger a fork of the entire kernel, with the vast majority of the community using the forked version as the new source of truth.

          This is not preventative maintenance. This is fixing something that’s not broken, that has moreover worked reliably, performantly (enough), and correctly for literal decades. You do not let a black box rewrite your whole codebase in another language and then expect everything to magically work.