• @yggdar@lemmy.world
    link
    fedilink
    487 months ago

    You want to translate COBOL to another language? That exists as a commercial product! The complexity is not the syntax though, it is the environment and subsystems surrounding the code. A lot of COBOL is designed for mainframe systems, and emulating a mainframe is complex.

    You also end up with code that is still written as if it were COBOL. The syntax for COBOL is the easy part and that is all you can easily replace. Afterwards you’re still stuck with the way of working and mindset, both of which are quite peculiar.

    The company I work for recently looked at all of this, and we decided not to translate our code.

    • @BestBouclettes
      link
      67 months ago

      Also, isn’t COBOL extremely fast ? Which is not necessarily true for newer languages

    • @jaybone@lemmy.world
      link
      fedilink
      4
      edit-2
      7 months ago

      Just make the devs learn the language if they don’t know it already. What kind of shitty mid to senior dev can’t learn a new language in a reasonable amount of time.

      • @abraxas@sh.itjust.works
        link
        fedilink
        4
        edit-2
        7 months ago

        I think it’s a matter of expertise. I am stuck dealing with people who write Javascript/Typescript like it’s C# because they’re C# senior devs. It’s not world-ending until issues of speed, scale, or other “why we use best practices” raise their ugly heads. Then it is world-ending. I can only help with so many design standards when you still see everything show up in a classes-and-subclasses mindset with hard-to-catch concurrency bugs. I actually caught a developer trying to spin up a child process to wait on a socket response.

        So in FinTech, I can imagine it becomes a bigger deal faster.