From: cross@spitfire.i.gajendra.net

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.

>But last century then Cobol and Basic were the two easiest
>languages to learn and Cobol was one of the languages with
>most jobs. So it seems likely that a large number of bad
>programmers picked Cobol. Bringing bad habits with them.
>
>Today I would expect that crowd to pick client side JavaScript
>and server side PHP.
>
>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.

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.

I have written about this many times.

	- Dan C.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)