From: bill.gunshannon@gmail.com

On 12/1/2025 4:02 PM, 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.

Not really true. The only thing COBOL professionals have, for
the most part, refused to use is the OOP stuff.  Some of the
other changes that are within the COBOL model were very welcome
additions.  Like EVALUATE.  Got rid of a lot of multiple page
IF-THEN-ELSE monstrosities.

bill

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)