From: cross@spitfire.i.gajendra.net   
      
   In article <10gkvoj$1me0l$2@dont-email.me>,   
   Arne Vajhøj   wrote:   
   >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.   
      
   Yup.  This is the thing that few COBOL fans seem to admit (hi,   
   Bill): they like to point out that most of the complaints about   
   COBOL are about very old versions of the language, and that most   
   of them have been addressed in recent revisions.  Ok, fair point   
   maybe, but irrelevant if the code base one is working in has not   
   been modernized to take advantage of those new facilities.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)