From: cross@spitfire.i.gajendra.net

In article ,
bill   wrote:
>On 12/1/2025 8:44 PM, Arne Vajhøj wrote:
>> On 12/1/2025 8:23 PM, bill wrote:
>>> [snip]
>>> UNICODE the same thing.  It could be done fairly easily with a library
>>> but isn't really anything that COBOL had to have as a part of the
>>> language.
>>
>> Good unicode support require support in both language and
>> basic RTL.
>
>Don't agree.  COBOL was intended to keep track of money, inventory,
>personnel, etc.  UNICODE, per se,  brings nothing to the table for
>any of that.  And, as designed, it did support alternate character
>sets.

Well, taking personnel as an example, people have names, don't
they?  Not everyone uses the Latin alphabet, and even for those
that (largely) do, some folks have diacritical marks in their
name and so forth.  It's nice to be able to represent those.

>> Classes is part of OOP that was added in Cobol 2002.
>
>And the COBOL Community refused to drink the Kool-Aid.
>While there may actually be a place for OOP, the work
>COBOL was intended to do isn't it.  Academia tried to
>force it down everyone's throats and were outraged
>when some refused. (And took their revenge which is
>being felt more and more every day now!!)  I know a
>number of massive ISes in use today that have been in
>use for around a half century that were written in COBOL
>and continue to function in COBOL. Lack of OOP hasn't
>affected them at all.

Maybe, maybe not, but what you are describing is survivorship
bias.  It's entirely possible that _some_ COBOL programs might
have benefited substantially from employing some OO techniques;
because they didn't really try, we don't know.

Consider a summarization report for a payroll run that is
sourced from data accumulated over the run.  This really isn't
my wheelhouse, but I could well imagine representing the
accumulated state in an object and doing the actual accumulation
via method calls on that object; perhaps part of the process of
accumulation is performing some transformation; that logic could
be centralized in those methods.

One doesn't need to do it that way, of course, but as an
organizational style it's honestly not bad, and would fit very
well into the types of tasks common in the COBOL world.

There's a lot of COBOL out there.  Maybe someone's tried this
and decided that it wasn't the best way to go about things.  But
that's qualitatively different than rejecting the idea out of
hand because it's an academic exercise in self-abuse.

>> Collection classes was added in:
>>
>> ISO/IEC TR 24717:2009, Information technology -- Programming languages,
>> their environments and system software interfaces -- Collection classes
>> for programming language COBOL
>>
>> I have never seen it used and I do not know how they work. But if it is
>> like collection classes in most other programming languages, then it
>> is predefined container classes for list, map/dictionary etc..
>
>Which does what for COBOL?

Makes it so that you never have to implement a linked list,
binary search tree, or hash table ever again.

I tend to think of COBOL as a DSL for expressing "business
logic": it's optimized for expressing relatively simple rules
applied over and over again across a large data set.  If that's
the case, then a COBOL programmer may never need those things.

But I imagine even COBOL folks like the flexibility of
data-driven designs, for which such things can be useful for
building lookup-tables and so forth.

	- Dan C.

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