Hacker News Reader

I don’t think COBOL does force you to mix concerns. You could create sub modules / services which you call from a main program to do things like file writing or database reading.

Java doesn’t also say you have to separate concerns. You could easily write a single method which mixes business logic and IO (file and DB)

When writing a batch program you need a balance between understanding it, making it efficient and reliable and promoting re-use (e.g. if many batch programs want the same behaviour break it into a reusable module). COBOL still has dependencies too, so each program is rarely written in isolation and you have to co-ordinate with other teams to ensure their module versions are in sync with yours.

The thing that has always let COBOL down for me is the lack of automated testing.

>>> Java doesn’t also say you have to separate concerns.

Sure, I was talking from inside my own enterprise-context where Java actually means Java + Spring + a few other things that force you to separate concerns (for the better imho, although it doesn't help with code navigation)

>>> The thing that has always let COBOL down for me is the lack of automated testing.

True.

I don't think most of those things are pluses for COBOL really, but if the alternative was what the Enterprise Java world has been doing for the past 10 or 15 years, bring on the COBOL.

> 2/ COBOL forces you to mix concerns : DB access, file I/O, business logic. This is sometimes useful to get a complete picture of what’s going on in a program. In Java, you have to wander through your DAO, data model, business logic, etc. which are spread everywhere.

Java doesn't force you. You can structure your code in many ways. In particular nothing is forcing you to have objects like Customer, Order, Invoice, etc. It is just the way OOP has been traditionally taught. Specifically in enterprise applications where a lot of the logic revolves around the data tables makes sense to have objects like CustomerTable, OrderTable, InvoiceTable and have all the related code encapsulated. See https://martinfowler.com/eaaCatalog/tableDataGateway.html https://martinfowler.com/eaaCatalog/transactionScript.html

All your points make a lot of sense. But it is not an essential part of the language. It is more about the culture prevalent with people using the language. But your point is well taken. Maybe we can learn from other programming cultures.

> 1/ COBOL run in closed environments. This allows these to be rock solid. (no such thing as a dependency nightmare). You don’t have such a thing as different version of Java on your testing and production environment.

Both Go and Java can do that (yes, without having to install a JVM on the target machine).

COBOL supports "includes" (called copybooks I think) which is poor-man's re-use but at least lets you avoid defining the same common record formats and subroutines individually in every program that needs them.