From: cross@spitfire.i.gajendra.net   
      
   In article <10gg48s$3srom$1@dont-email.me>,   
   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)   
   >   
   >> 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.   
   >   
   >> 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.   
      
   I've long suspected (but I admit I have no evidence to support   
   this) that one of the reasons there is so much COBOL code in the   
   world is because, when making non-trivial changes, programmers   
   first _copy_ large sections of the program and then modify the   
   copy, to avoid introducing bugs into existing functionality.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)