IBM taps AI to translate COBOL code to Java | TechCrunch
techcrunch.com
IBM's new product offering, Code Assistant for IBM Z, leverages a generative AI model to translate COBOL code to Java.

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 🙏

  • aksdb@feddit.de
    17·
    1 year ago

    What pisses me off about many such endeavors is, that these companies always want big-bang solutions, which are excessively hard to plan out due to the complexity of these systems, so it’s hard to put a financial number on the project and they typically end up with hundreds of people involved during “planning” just to be sacked before any meaningful progress could be made.

    Instead they could simply take the engineers they need for maintenance anyway, and give them the freedom to rework the system in the time they are assigned to the project. Those systems are - in my opinion - basically microservice systems. Thousands of more or less small modules inter-connected by JCL scripts and batch processes. So instead of doing it big bang, you could tackle module by module. The module doesn’t care in what language the other side is written in, as long as it still is able to work with the same datastructure(s).

    Pick a module, understand it, write tests if they are missing, and then rewrite it.

    After some years of doing that, all modules will be in a modern language (Java, Go, Rust, whatever) and you will have test coverage and hopefully even documentation. Then you can start refactoring the architecture.

    But I guess that would be too easy and not enterprisy enough.

    • gedhrel@lemmy.ml
      2·
      1 year ago

      I think you vastly overestimate the separability of these systems.

      Picture 10,000 lines of code in one method, with a history of multiple decades.

      Now picture that that method has buried in it, complex interactions with another method of similar size, which is triggered via an obscure side-effect.

      Picture whole teams of developers adding to this on a daily basis in realtime.

      There is no “meaningful progress” to be made here. It may offend your aesthetic sense, but it’s just the reality of doing business.

      • aksdb@feddit.de
        2·
        1 year ago

        What’s the alternative in your opinion?

        Not doing anything and keep fiddling around in this mess for the next 20 years?

        Continue trying to capture this problem big-bang, which means not only dealing with one such unmaintainable module but all of them at once?

        Will every module be a piece of cake? Hell no. But if you never start anywhere, it doesn’t get better on its own.

        • gedhrel@lemmy.ml
          1·
          1 year ago

          The alternative is to continue with a process that’s been demonstrably successful, despite it offending your sensibilities.

          Banks are prepared to pay for it. People are prepared to do it. It meets the business needs. Change is massively high-risk in a hugely conservative industry.