3 ms·

I'm not sure this would help - COBOL itself is already fairly readable. The problem is that a program doesn't actually contain a full description of the busine

I'm not sure this would help - COBOL itself is already fairly readable. The problem is that a program doesn't actually contain a full description of the business problem - it only contains what's necessary for the machine to solve the business problem. For example, the system may never be designed to process check deposits on a Sunday (and a lot of date-related calculations will go wrong if you tried to), but guarding against that is accomplished by the "real world" - there's nobody there to file in check deposit requests on those days. Yet, there's nothing explicit in the code about preventing check deposits on a Sunday, so your hypothetical decompiler will have no way to infer that without outside knowledge. What you need is a hypothetical magical decompiler that given a binary or source code as input, will spit out the actual business problem and all the edge-cases it's meant to solve. AI might eventually get us very close to that, but ultimately it'll still be a guessing game.

derefr 4y ago
It sounds like you're increasing the scope of the problem relative to what it needs to be. (And you're not alone: that's seemingly what every bigcorp who tries to do this does, and that's why they all fail.) AFAICT the goal of such a translation effort should just be to replace a COBOL codebase that does X, with a codebase in a more-maintainable language that also does exactly X, in a bug-for-bug-compatible way. You don't need to know the business requirements that led to the implementation; you just need to take the existing implementation, with its embodied institutional knowledge, and blindly preserve that knowledge by not making any top-down assumptions about the requirements that would accidentally design it out, but instead preserving the bottom-up structure. If you like, you can re-do the requirements analysis and top-down refactor the program later on — after you've already "decompiled" it into a workable HLL. An analogy. Say there was an unfinished manuscript of a novel written in Old English. You want to have this published as a modern novel. You have two choices: either you — someone who presumably can read Old English — try to do a top-down rewrite of the manuscript into a modern-English novel, figuring out the plot and characters from the manuscript and copying that "design" to a new modern-English novel; or, you just translate the manuscript itself into modern English, sentence by sentence, and then, after you have now acquired a modern-English manuscript, set about turning that manuscript into a finished novel through the normal prose editing tools of structural editing and copyediting. I think you can see how the former approach is pretty silly; and yet is exactly what people do when they attempt to build a new system from the ground up to replace a legacy system. The former approach severely limits the number of people who can understand+reference the old design when working on the new design, while the latter approach does not. The latter approach allows the "turns of phrase" of the old work to be reused as-is in the new work, while the former approach does not.

derefr 4y ago

It sounds like you're increasing the scope of the problem relative to what it needs to be. (And you're not alone: that's seemingly what every bigcorp who tries to do this does, and that's why they all fail.) AFAICT the goal of such a translation effort should just be to replace a COBOL codebase that does X, with a codebase in a more-maintainable language that also does exactly X, in a bug-for-bug-compatible way. You don't need to know the business requirements that led to the implementation; you just need to take the existing implementation, with its embodied institutional knowledge, and blindly preserve that knowledge by not making any top-down assumptions about the requirements that would accidentally design it out, but instead preserving the bottom-up structure. If you like, you can re-do the requirements analysis and top-down refactor the program later on — after you've already "decompiled" it into a workable HLL. An analogy. Say there was an unfinished manuscript of a novel written in Old English. You want to have this published as a modern novel. You have two choices: either you — someone who presumably can read Old English — try to do a top-down rewrite of the manuscript into a modern-English novel, figuring out the plot and characters from the manuscript and copying that "design" to a new modern-English novel; or, you just translate the manuscript itself into modern English, sentence by sentence, and then, after you have now acquired a modern-English manuscript, set about turning that manuscript into a finished novel through the normal prose editing tools of structural editing and copyediting. I think you can see how the former approach is pretty silly; and yet is exactly what people do when they attempt to build a new system from the ground up to replace a legacy system. The former approach severely limits the number of people who can understand+reference the old design when working on the new design, while the latter approach does not. The latter approach allows the "turns of phrase" of the old work to be reused as-is in the new work, while the former approach does not.