From: arne@vajhoej.dk   
      
   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.   
      
   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.   
      
   > 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.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)