From: arne@vajhoej.dk   
      
   On 12/1/2025 8:37 AM, Dan Cross wrote:   
   > In article <10gg48s$3srom$1@dont-email.me>,   
   > Dave Froble   wrote:   
   >> On 11/11/2025 10:23 AM, Waldek Hebisch wrote:   
   >>> Defining a function need a several lines of   
   >>> overhead code.  Function calls are more verbose than in other   
   >>> languages.  There are fixable problems, which however may   
   >>> appear when dealing with real Cobol code.  In particular   
   >>> Cobol support old control structures.  In new program you   
   >>> can use new control structures, but convering uses of old   
   >>> control strucures to new ones need effort and it is likely   
   >>> that a bit more effort would be enough to convert whole   
   >>> program to a different language.   
   >>   
   >> I apologize in advance, but that is idiotic.  Any re-write of any   
   non-trivial   
   >> application in another language, will never be complete. There will be   
   errors   
   >> and things will be lost.  IT   WILL   HAPPEN   !!!  And when done, what   
   will be   
   >> the gains in a sideways move?   
   >   
   > I got the impression Waldek was referring to updating programs   
   > written to old versions of COBOL to use facilities introduced in   
   > newer versions of COBOL, though perhaps I am mistaken.   
   >   
   > Regardless, this raises an interesting point: the latest version   
   > of COBOL is, I believe, COBOL 2023.  But that language is rather   
   > different than the original 1960 COBOL.  So even simply updating   
   > a COBOL program is akin to rewriting it in another language.   
      
   The Cobol standard has been continuously updated over   
   the decades. But very few are using the new stuff added   
   the last 25 years.   
      
   For good reasons.   
      
   Let us say that a company:   
   * have a big Cobol application   
   * want to add a significant chunk of new functionality   
   * that new functionality could be implemented using   
      features from recent versions of Cobol standard   
      
   Options:   
   A) implement it in Cobol using features from recent   
       versions of Cobol standard and have the team learn   
       the new stuff   
   B) implement it in old style Cobol, because that is what   
       the team knows   
   C) implement it in some other language where the functionality is   
       common and call it from Cobol   
   D) implement it in some other language where the functionality is   
       common and put it in a separate service in middleware tier and   
       keep the old Cobol application untouched   
   E) say NO - can't do it   
      
   Few will choose #A. #B, #C and #D are simply more attractive.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)