From: arne@vajhoej.dk   
      
   On 7/11/2025 5:58 PM, Stephen Hoffman wrote:   
   > On 2025-07-06 12:52:22 +0000, Waldek Hebisch said:   
   >> There are no indicatianos of substantial reimplementation.  Official   
   >> info says that new or substantially reworked code is in C.  But w also   
   >> have information that amount of Macro32 and Bliss did not   
   >> substantially decrease.  So, (almost all) old code is still in use.   
   >> It could be that small changes to old code took a lot of time. It   
   >> could be that some new pieces were particularly tricky. However, you   
   >> should understand that porting really means replicating exisiting   
   >> behaviour on new hardware.  Replicating behaviour gets more tricky if   
   >> you change more parts and especially if you want to target a high   
   >> level interface.   
   >   
   > You're correct. Reworking existing working code is quite often an   
   > immense mistake.   
   >   
   > It usually fails. If not always fails.   
   >   
   > And bringing a source-to-source translation tooling or an LLM can be   
   > helpful, and can also introduce new issues and new bugs.   
   >   
   > About the only way a global rewrite can succeed — absent a   
   > stratospheric-scale budget for the rewrite, and maybe not even then — is   
   > an incremental rewrite, as the specific modules need more than trivial   
   > modifications.   
      
   Large applications get rewritten all the time.   
      
   The failure rate is pretty high, but there are also lots of successes.   
      
   Two key factors for success are:   
   - realistic approach: realistic scope, realistic time frame and   
      realistic budget   
   - good team - latest and greatest development methodology can not   
      make a bad team succeed - people with skills and experience are   
      needed for big projects   
      
   The idea of a 1:1 port is usually bad. Yes - you can implement the   
   exact same flow of your Cobol application in Java/C++/Go/C#,   
   but that only solves a language problem not an architecture problem.   
   You need to re-architect the solution: from ISAM to RDBMS,   
   from vertical app scaling to horizontal app scaling, from 5x16 to   
   7x24 operations etc..   
      
   And that is the problem with the incremental rewrite - it lean   
   more to existing architecture than changing architecture. The   
   strangler pattern is rarely practical to implement.   
      
   As an example of a success story Morgan Stanley recently told   
   that they rewrote 9 million lines of Cobol using a LLM. But smart   
   people - they did not let the LLM auto-convert the code (that   
   would likely have resulted in a big mess) - instead they   
   let the LLM document the code and produce requirements for the   
   new code.   
      
   > Reworking a project of the scale of OpenVMS — easily a decade-long   
   > freeze — and for little benefit to VSI.   
      
   True. It is difficult to see the business case for that.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)