[js8]

(I work in mainframes, but not directly COBOL.) COBOL could certainly be done better today, but its strength comes from the fact that it limits what programmers can do with it.

In the past, there was a divide between systems and application programmers. Roughly, the systems programmers took care about the details of the infrastructure and resource access, while the application programmers worried about the "business logic" of the applications.

After the microcomputer revolution, new languages emerged and this divide was lost. "Modern" languages such as C or Java do not make this distinction. Today, programmers are supposed to be interchangeable, and they are supposed to work equally well on system infrastructure and application logic. I suspect it's partly the pride, because infrastructure work is often seen as more attractive - all the distributed algorithms stuff, scaling, etc.

To me interesting question is, was this divide valuable and should we return to it? I think so. With the advent of functional programming, it is possible to understand applications a layers of translation between different languages (see https://degoes.net/articles/modern-fp-part-2), where the language of the business problem is at the top layer, and the language of the operating system is at the bottom layer. The (application) programmers, working on the upper layers, should specialize in the application domain, and the (system) programmers, working on the lower layers, should specialize in computer systems.

[le-mark]

> In the past, there was a divide between systems and application programmers. Roughly, the systems programmers took care about the details of the infrastructure and resource access, while the application programmers worried about the "business logic" of the applications.

I would add that in the era cobol was designed and rose to prominence, assembler was used for both. Cobol enshrined the application assembler practices of the time, all memory was statically declared, no dynamic memory allocation, no call stack, just gotos and conditional branching, and mapping fixed length data from tape drives into memory. Note this all made cobol very stable and even secure (no possibility for buffer overflows for example).

Also clearly not what was needed for true systems programming.

[DoomHotel]

We used PERFORM to implement calls. Whether or not implemented with a stack, it acts the same as any call/return. So to implement a simple loop to count records in a file:

PERFORM COUNT-ROWS VARYING COUNT FROM 1 BY 1 UNTIL EOF.

And the callee did:

READ INPUT-FILE AT END MOVE 1 TO EOF-FLAG.

[ASalazarMX]

Ah, the joys of forgetting to put a period at the end of the COUNT-ROWS paragraph.

[DoomHotel]

We had some coding rules to help prevent that:

1. No unnecessary periods in the code

2. Required periods (ending paragraphs and if/then/else) go on a line by themselves

[pjmlp]

Actually I think this divide still exists, just at another level.

For example when I write Java code, I don't care if the VM is implemented in C, C++, Assembly, hardware or whatever.

Just like when I upload the jar file into a cloud instance app engine, usually I don't care if the JVM is running on top of some OS, bare metal or whatever it making it run.

Yet, there is a group of developers that is making that illusion possible for the rest of us.

[PedroBatista]

But you have to care about FileInputStreams, bytes and CompletableFutures.

The "best" we have to offer today as "pure" business logic programing is some BPMN framework/platform.. and that is mostly hell of Earth..

COBOL is not coming back because that time has passed, however something with the basic essence and principals of COBOL is desperately needed. Don't ask me what and how because I don't know either.

[Zababa]

> The "best" we have to offer today as "pure" business logic programing is some BPMN framework/platform.. and that is mostly hell of Earth..

Do cloud plateforms fall under BPMN frameworks/plateforms? From what I understand, it's possible to build applications today using cloud plateforms (AWS and Azure mostly, I don't know about the others) for auth, persistance, etc; while only writing your business logic, especially now with serverless where you only write functions.

In a way this is the return of the distinction between application and system, but the system is left to another company. This would fit with the (anecdotal) pattern I've noticed where before companies had cleaning people, IT people, etc and now everything is subcontracted to other companies.

[pjmlp]

For me the "cloud" just feels like back to UNIX proper days, just that instead of using telnet on a green phosphor terminal or an IBM X Windows terminal, I use the browser alongside a cloud shell.

[pjmlp]

Depends, in the context of COBOL that would be some ORM library.

[bigbillheck]

If that divide was ever absent, it wasn't absent for long. 'Application programmers' had BASIC in the 80s, Visual BASIC (and delphi hypercard and tcl/tk) in the 90s, then the 00s hit and with it ruby and python and the biggest application language of them all, javascript.

[snidane]

Cloud is the new mainframe. The split between infrastructure (platform) and application engineers is back.

[nradov]

Java is the new Cobol. Java was always intended as an applications language. Due to GC and lack of direct memory access it's not really suitable for systems programming.