3 ms·

Here's a crazy idea (and possibly a job opportunity for someone?) If someone built a tool to translate the AST generated by this into one of these newer theore

Here's a crazy idea (and possibly a job opportunity for someone?) If someone built a tool to translate the AST generated by this into one of these newer theorem-proving dependently-typed languages (examples: Idris/Idris2 come to mind, but also the Coq/Rocq theorem prover, Agda, Lean), would it be theoretically possible to not only translate this code into a newer language but also suss out bugs and literally prove correctness? (Given how important some of this COBOL code seems to be, such as at Medicare) I know that one of the risks of changing the language that logic and computation is written in is unexpectedly changing the behavior or introducing new bugs; wondering if this might mitigate or almost entirely prevent that

armorer 2y ago
It's not a crazy idea. For example, Amazon's BluAge offering does automatic translation. However, frequently, forward engineering teams do not want a 1:1 translation of the code, because that might end up reproducing the same system organisation of the original Cobol base (in a modern language), and engineers/architects usually want to work on a new design (while maintaining the original domain logic). So far, this library does not step into the forward engineering territory, and tries to merely provide useful information/artifacts, which could help the reverse engineering teams move (hopefully) faster, but obviously there is a lot of experimentation / inference that can be done on top of the extracted data.
- Closi 2y ago
  Depends - sometimes/often the goal is just to bring it into a modern language to improve maintainability (i.e. its an easier hire) rather than to do a ground-up rewrite. Especially as ground-up rewrites are often risky, and bringing it into a modern language might make it easier to incrementally improve/refactor over time.
  - SonOfLilit 2y ago
    When people say "bring this cobol code to a new language to improve maintainability", they don't just mean the syntax. Any C developer can learn cobol syntax in 10 minutes. They mean things like use functions instead of gotos, don't use just global variables, don't depend on lots of weird tooling from the parallel world of IBM mainframes, with most of your logic hidden in weird batch scripts with names like ABC@@DEF. I could write a cobol to c translator in a weekend. Nobody would buy it. Source: I've spent the last year and a half consulting on a huge project to rewrite a cobol codebase.
    - pmarreck 2y ago
      So basically the real work is not syntax translation (which a machine could do, albeit probably poorly) but semantics translation (which requires a deep understanding of both languages as well as what the code's intent is), so that you can do things like replace goto's with function calls without breaking expected behavior given inputs. A similar problem to translating procedural code in a language with mutable variables to functional code in a language with immutable variables. A lot of old functions in C etc. were expected to modify their passed-in arguments, for example, which would be a no-no today (note: not in the C space, I'm currently an Elixir dev, but I'm hoping that's now frowned upon!) I've noticed that LLM's are still not very good at this, too. I'm unfamiliar with COBOL but I'm currently looking for work; not sure if you'd be up for a conversation just to discuss your work since (for some odd reason) I enjoy refactoring (as well as software preservation and validation); at the very least I'd probably be a decent rubber-duck if you got stuck on something lol
      - SonOfLilit 2y ago
        Reading COBOL and translating its behavior 1:1 is maybe 1% of my job. There is so much more to modernising a bank. Technologically and culturally. I can discuss my work, but unless you have a work permit in Israel, I won't be able to hire you.
        pmarreck 2y ago
        Ha, now I get the username! Without getting into specifics, is it rewarding work? I can probably not do terrible at the 99% part
        SonOfLilit 2y ago
        To get the username you'd need to be familiar with at least the old Hebrew translation of Lord of the Rings and my mother :) I'm enjoying tech-leading this project very much. I get to spend the time needed to write unusually high quality code, and there's a wide funnel that collects interesting debugging challenges and gets the best ones to my desk. Working with a bank is... not for everyone. Not for me ten years ago, for example.
mgsouth 2y ago
Fully automated? I don't think so, and it falls apart suprisingly quickly. To give an example: All variables (well, in "classical COBOL" at least) are global variables. Since memory is constrained, a really common idiom is to have great swathes of punned, overlayed variables; in C terms it would be unioned structs. Subroutine A would have a var A-TEMPS divided into A-TEMP-VAR1 and A-TEMP-VAR2. Since routine B isn't on the same call path, that _same area_ could be also divided into B-TEMPS, B-TEMP-X, B-RESULT, and C-MOVEIN (because hey, code got changed). When you port this mess to Java you can (a) emulate unions with mind-boggling complex , huge, and fragile idioms, (b) tease out the actual code flow graphs and intent, or (c) some combination. And no, automated doesn't go very far for (b); although the computer might be able to figure out that March doesn't have a leap day and so this path won't execute because of that, it _is_ the end of a quarter and so has an artificial closing-day tacked on _if_ this is for subsidiary Foo, but not Bar because they have a 0-day on the following month. Too many combinations to exhaustively compute, and requires a lot of human smarts to prune possibilities.

armorer 2y ago

It's not a crazy idea. For example, Amazon's BluAge offering does automatic translation. However, frequently, forward engineering teams do not want a 1:1 translation of the code, because that might end up reproducing the same system organisation of the original Cobol base (in a modern language), and engineers/architects usually want to work on a new design (while maintaining the original domain logic). So far, this library does not step into the forward engineering territory, and tries to merely provide useful information/artifacts, which could help the reverse engineering teams move (hopefully) faster, but obviously there is a lot of experimentation / inference that can be done on top of the extracted data.

Closi 2y ago
Depends - sometimes/often the goal is just to bring it into a modern language to improve maintainability (i.e. its an easier hire) rather than to do a ground-up rewrite. Especially as ground-up rewrites are often risky, and bringing it into a modern language might make it easier to incrementally improve/refactor over time.
- SonOfLilit 2y ago
  When people say "bring this cobol code to a new language to improve maintainability", they don't just mean the syntax. Any C developer can learn cobol syntax in 10 minutes. They mean things like use functions instead of gotos, don't use just global variables, don't depend on lots of weird tooling from the parallel world of IBM mainframes, with most of your logic hidden in weird batch scripts with names like ABC@@DEF. I could write a cobol to c translator in a weekend. Nobody would buy it. Source: I've spent the last year and a half consulting on a huge project to rewrite a cobol codebase.
  - pmarreck 2y ago
    So basically the real work is not syntax translation (which a machine could do, albeit probably poorly) but semantics translation (which requires a deep understanding of both languages as well as what the code's intent is), so that you can do things like replace goto's with function calls without breaking expected behavior given inputs. A similar problem to translating procedural code in a language with mutable variables to functional code in a language with immutable variables. A lot of old functions in C etc. were expected to modify their passed-in arguments, for example, which would be a no-no today (note: not in the C space, I'm currently an Elixir dev, but I'm hoping that's now frowned upon!) I've noticed that LLM's are still not very good at this, too. I'm unfamiliar with COBOL but I'm currently looking for work; not sure if you'd be up for a conversation just to discuss your work since (for some odd reason) I enjoy refactoring (as well as software preservation and validation); at the very least I'd probably be a decent rubber-duck if you got stuck on something lol
    - SonOfLilit 2y ago
      Reading COBOL and translating its behavior 1:1 is maybe 1% of my job. There is so much more to modernising a bank. Technologically and culturally. I can discuss my work, but unless you have a work permit in Israel, I won't be able to hire you.
      - pmarreck 2y ago
        Ha, now I get the username! Without getting into specifics, is it rewarding work? I can probably not do terrible at the 99% part
        SonOfLilit 2y ago
        To get the username you'd need to be familiar with at least the old Hebrew translation of Lord of the Rings and my mother :) I'm enjoying tech-leading this project very much. I get to spend the time needed to write unusually high quality code, and there's a wide funnel that collects interesting debugging challenges and gets the best ones to my desk. Working with a bank is... not for everyone. Not for me ten years ago, for example.

mgsouth 2y ago

Fully automated? I don't think so, and it falls apart suprisingly quickly. To give an example: All variables (well, in "classical COBOL" at least) are global variables. Since memory is constrained, a really common idiom is to have great swathes of punned, overlayed variables; in C terms it would be unioned structs. Subroutine A would have a var A-TEMPS divided into A-TEMP-VAR1 and A-TEMP-VAR2. Since routine B isn't on the same call path, that _same area_ could be also divided into B-TEMPS, B-TEMP-X, B-RESULT, and C-MOVEIN (because hey, code got changed). When you port this mess to Java you can (a) emulate unions with mind-boggling complex , huge, and fragile idioms, (b) tease out the actual code flow graphs and intent, or (c) some combination. And no, automated doesn't go very far for (b); although the computer might be able to figure out that March doesn't have a leap day and so this path won't execute because of that, it _is_ the end of a quarter and so has an artificial closing-day tacked on _if_ this is for subsidiary Foo, but not Bar because they have a 0-day on the following month. Too many combinations to exhaustively compute, and requires a lot of human smarts to prune possibilities.