4 ms·

I have regualr talks with people who were using COBOL a while ago. There are things were cobol is good : 1/ COBOL run in closed environments. This allows these

by wiz21c 9y ago

I have regualr talks with people who were using COBOL a while ago. There are things were cobol is good : 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. 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. 3/ Code resue is hard to acheve so there is some copy/paste. That is sometimes good in the sense that if you fix a program, you won’t accidentally introduce a bug in a copy of that program. (many of us will scream at reading this, but consider it). 4/ Of course COBOL programmers are good too and they use these old practices in a sensible way 5/ COBOL technologies don’t change often. So there’s no discussion about changing your framework. When you write software that must last for at least 10 years, this makes choices easier.

planetjones 9y ago
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.
- wiz21c 9y ago
  >>> 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.
  - deong 9y ago
    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.
ams6110 9y ago
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.
corpMaverick 9y ago
> 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/tableDataGateway.html https://martinfowler.com/eaaCatalog/transactionScript.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.
Tijdreiziger 9y ago
> 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).

by wiz21c 9y ago

planetjones 9y ago

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.

wiz21c 9y ago
>>> 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.
- deong 9y ago
  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.

ams6110 9y ago

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.

corpMaverick 9y ago

> 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/tableDataGateway.html https://martinfowler.com/eaaCatalog/transactionScript.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.

Tijdreiziger 9y ago

> 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).