[kimi]

There are a few things that the author forgot:

- COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why.

- COBOL programs do what they do. They do not have specs, but if that's the way we have been computing account interests for the last 50 years, they are right. It's lawyers documenting them, not the other way around.

- COBOL programmers were often meant to be "less" than real programmers. More like junior accountants automating boring procedures, than C wizards. Wizards would not touch COBOL code with a stick. This often shows.

This said, the kind of things you could do on a IBM mainframe in the '70s (virtualization, data safety and efficiency, disaster recovery, even uptime) still run rings around the 90-core boxes with Linux that are in your datacenter racks.

[wtetzner]

> COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why.

I wonder how different it would be if they had a good source control system (and used it). Would you be able to look at the history and understand why the changes were made, or would you just get a bunch of commit messages like "made update" or "reverted earlier change"?

[opsunit]

Having worked on the PL/1 and Assembler that formed the core accounting systems of a bank: yes.

Not only did I have source control I had flow diagrams of the entire system for all points in the chain. My code reviews had me doing line-by-line justifications. I wrote tests.

Just because the technology and practitioners are old it doesn't mean they don't know what they're doing.

Generally they invented whatever "you" are reinventing the first time around.

[kimi]

COBOL was used for more mundane tasks - a lot of data loading, formatting, batches of all kinds. Not all of which seemed so important when they were written, but that ended up being a plug nobody wants to take the risk of disconnecting.....

[coldtea]

If they're still run, they're still important if not crucial.

I don't think they do data loading and batch processing on stuff they don't need.

[kimi]

Exactly. But sometimes they were built as a "quick patch, we'll do this right later" and then improved and changed and.... you see the picture.

[wtetzner]

> Just because the technology and practitioners are old it doesn't mean they don't know what they're doing.

I certainly didn't mean to imply that. It's more that many people now don't do a good job with that stuff, so I was curious if it would have been better then.

[BitwiseFool]

In my professional experience, code comments and commit messages only cursorily reflect the change in the business logic that prompted the modifications. I suspect this is because the knowledge of the client's business logic is concentrated in the product managers' domain and not in the programmers' domain. All of the back and forth emails with the customer don't get included in our SCM.

[goalieca]

Imagine they used jira, confluence, and git. It would still be a huge no! Code archeology is a real necessity even on a <10 year old system. The best way to find out about something is to have a chat with a ‘historian’ who has been with the company for 10+ years.

[theamk]

It depends on team culture at a time.

There are teams which require all changes come via defined channel (like bug tracker or special email), and which put ticket # in each commit (like Gitlab -- see the "closes #..." at the commit message [0])

But many teams have no procedure, or the procedure is optional -- and there you can easily get "made update" commits.

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56794

[khooke]

I worked at 3 different companies in the mid 1990s that had teams actively working on COBOL systems and they were all using mainframe based version control systems. I think the issue at this point is whether those version control systems are still being maintained and those orgs are continuing to pay for the licenses for those systems, probably during years where you weren't even planning on using them.

[908B64B197]

> COBOL programs do what they do. They do not have specs

And nothing around them is standard either. No database, no best practices, no comments in code. Combined with

> OBOL programmers were often meant to be "less" than real programmers.

you get programs that are completely unmaintainable. Contrast this with the first versions of UNIX or BSD (written around the same time) and you can still build and understand them pretty easily. That's the difference between programmers and software engineers.

> This said, the kind of things you could do on a IBM mainframe in the '70s (virtualization, data safety and efficiency, disaster recovery, even uptime) still run rings around the 90-core boxes with Linux that are in your datacenter racks.

All through obscure, proprietary APIs and along with a hefty support contract from IBM. Making sure nobody in academia or in SV could get within 500m of a mainframe sure helped them become more than a niche.