From: cross@spitfire.i.gajendra.net   
      
   In article <10gn0cq$2d8ve$1@dont-email.me>,   
   Arne Vajhøj   wrote:   
   >On 12/2/2025 8:50 AM, Dan Cross wrote:   
   >> In article <10gle2k$1q97g$1@dont-email.me>,   
   >> Arne Vajhøj   wrote:   
   >>> On 12/1/2025 8:37 AM, Dan Cross wrote:   
   >>>> 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.   
   >>>   
   >>> Copying and modifying code instead of creating reusable libraries   
   >>> has been used by bad programmers in all languages.   
   >>   
   >> I think it's a little deeper than that.   
   >   
   >>> There is also something in the Cobol language.   
   >>>   
   >>> Large files with one data division, lots of paragraphs   
   >>> and lots of perform's is easy to code, but it is also   
   >>> bad for reusable code.   
   >>>   
   >>> It is sort of the same as having large C or Pascal files   
   >>> with all variables global and all functions/procedures   
   >>> without arguments.   
   >>>   
   >>> It is possible to do it right, but when people have   
   >>> to chose between the easy way and the right way, then ...   
   >>   
   >> An issue with COBOL is that, given procedures A, B, ..., Z,   
   >> written sequentially in source, `PERFORM A THRU Z` means that it   
   >> is difficult to see when procedures B, C, ..., Y are called just   
   >> through visual inspection since calls to them are implicit; you   
   >> really need semantically aware tools to do that.  So if you need   
   >> to change paragraph D, then you run the risk of implicitly   
   >> changing dependent behavior in your system unintentionally.  You   
   >> might end up violating some assumption you didn't even know   
   >> existed; talk about spooky action at a distance.   
   >   
   >That is a classical argument found on the internet.   
      
   Yes.  I myself have been making it for years.   
      
   >But I am not convinced that it is critical.   
   >   
   >It is all within one file.   
   >   
   >$ search foobar.cob thru,through   
   >   
   >should reveal if the feature is used.   
   >   
   >Unless the file is very long and the code is very ugly, then   
   >I believe it should be relative easy possible to track the   
   >perform flow even in VT mode EDT or EVE.   
      
   I'm not at all convinced of that in a large code base; call   
   graphs resulting in such `PERFORM`s can be too big to trace by   
   hand.  And many of these extant COBOL applications are quite   
   large, indeed.   
      
   >> Most COBOL programs were written before the era of automated,   
   >> unit-level testing, so it's extremely unlikely you've got a big   
   >> suite of tests you can run to attempt to catch such issues.   
   >>   
   >> I imagine that a this results in a lot of (unnecessary)   
   >> duplication.   
   >   
   >That may actually have a huge impact.   
   >   
   >No unit tests is a common reason not to change any existing code.   
      
   I'm sure that it does.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)