From: antispam@fricas.org
bill wrote:
> On 11/10/2025 9:12 AM, Simon Clubley wrote:
>>
>>
>> Question: are they low-risk because they were designed to do one thing
>> and to do it very well in extremely demanding environments ?
>>
>> Are the replacements higher-risk because they are more of a generic
>> infrastructure and the mission critical workloads need to be force-fitted
>> into them ?
>>
>
> And here you finally hit the crux of the matter.
> People wonder why I am still a strong supporter if COBOL.
> The reason is simple. It was a language designed to do
> a particular task and it does it well. Now we have this
> desire to replace it with something generic. I feel this
> is a bad idea.
Well, Cobol represents practices of 1960 business data
processing. At that time it was state of the art.
But state of the art changed. Cobol somewhat adapted
but it slow to this. So your claim of "does it well"
does not look true, unless by "it" you mean
"replicating Cobol data processing from the sixties".
To expand a bit more, Cobol has essentially unfixable problem
with verbosity. 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.
BTW: VSI Cobol manual documents in reasonable detail old
constructs, but leaves almost undocumented new features.
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
