From: antispam@fricas.org
Dave Froble wrote:
> On 11/11/2025 10:23 AM, Waldek Hebisch wrote:
>> 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.
>
> Sometimes things don't really change. You count to 10 the same way now as in
> 1960. (Trivial example)
Sometimes you may be able to do your data processing as in 1960.
But it is very unlikely to be good way now.
>> 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.
>
> Now this is opinion, and really a poor argument. While I detest the
verbosity
> in most things, that is my choice, not the problem you claim.
Once you have choosen Cobol you can not avoid verbosity (you can
make it even more verbose if you want, but can not avoid it due
to way the language works). And while I sometimes may choose more
verbose way of expressing things if I think that it helps clarity,
Cobol verbosity is essentially worthless, Cobol forces you to
write more code for frequently used constructs that could be
written more concisely in other languages and what is important
more concise way does not cause any confusion.
>> 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?
Point is that change to new control structures is not unlike
change to another language. If done by hand on non-trivial
application may lead to error. Concerning your "never", successful
conversions to a different langage did happen. Sensible convertion
is likely to be a semiautomatic process, doing changes by hand is too
labor intensive and risks errors, fully automatic process may be
impossible, but combination may work. Concerning gains,
goal is easier maintanence. If a program works fine and there
is little demand for modifications/additions, then cost and risk
of changes is likely to dominate and program will be kept as
is, meaning that ongoing maintanence will have to deal with
old style code and related problems.
Usual trap is that people used to old ways, especially ones using
single language have trouble programming well in newer languages.
And new people prefer writing new code to working with old code.
Which leads to rewrites loosing features/solutions present in
old code, cost overruns when people doing rewrite realize that
problem is harder than they expected etc.
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
