A Historical Perspective on COBOL (2020)
logicmag.io
A Historical Perspective on COBOL (2020)
1–10 of 39 posts
Re: A Historical Perspective on COBOL (2020)
#2(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.
Re: A Historical Perspective on COBOL (2020)
#3The article broadly claims that COBOL is viewed dismissively compared to other languages of similar vintage like C or FORTRAN, because unlike those latter it did not come out of a "research-oriented context". However, as a matter of fact, neither C nor FORTRAN came out of academia; much like COBOL, they were developed for practical use as opposed to "research". ISTM that the perceived issues with COBOL must be explained in some other way.
Re: A Historical Perspective on COBOL (2020)
#4(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…
> 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.
Re: A Historical Perspective on COBOL (2020)
#5This article's opinion of COBOL is too positive, even if I agree that COBOL is sometimes treated too harsh.
The failings of COBOL are the failings of slow, bureaucratic entities. It works, but needs constant manual handholding to keep it on the rails. It assumes plenty of butts in seats with plenty of time. It assumes nobody complains if results are a week late and the first version is wrong. It assumes end users will threat it gently, do a lot of interpreting of codes themselves, and can be fired if they look behind the curtain.
These are not unavoidable technical blockers, but every programming language also carries a specific culture within it.
None of this should block unemployment payments, but all of this places COBOL firmly in the sixties to maybe eighties.
Re: A Historical Perspective on COBOL (2020)
#6The article broadly claims that COBOL is viewed dismissively compared to other languages of similar vintage like C or FORTRAN, because unlike those latter it did not come out of a "research-oriented context". However, as a matter of fact, neither C nor FORTRAN came out of academia; much like COBOL, they were developed for practical use as opposed to "research". ISTM that the perceived issues with COBOL must be explai…
C has roots of its usage in academia, the same way Unix does.
I suspect, compared to other OSes of the era (Multics, MVS..), Unix doesn't require too much centralized control of (timeshared) operating system resources; for example the security model is extremely simple. So it was readily adopted in academia, because of this perceived user freedom (you just need a shell and you're good to go), and from there it spread to the industry.
So C and FORTRAN didn't came out of the academia, but were more widely adopted by it, which influenced later generations of students.
Re: A Historical Perspective on COBOL (2020)
#7(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…
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.
Re: A Historical Perspective on COBOL (2020)
#8This article's opinion of COBOL is too positive, even if I agree that COBOL is sometimes treated too harsh. The failings of COBOL are the failings of slow, bureaucratic entities. It works, but needs constant manual handholding to keep it on the rails. It assumes plenty of butts in seats with plenty of time. It assumes nobody complains if results are a week late and the first version is wrong. It assumes end users wil…
I haven't written cobol since late 90s-early 2k...
But my experiences were just the opposite. If you need to write accounting software, COBOL is a pretty painless way to do it. Add in something like automatic copybooks from DDL in file metadata (like the OS/400 supported) and it was great never having to worry about people forgetting to update record layouts.
the result was you could knock out your typical accounting stuff fairly quickly..
Re: A Historical Perspective on COBOL (2020)
#9The article broadly claims that COBOL is viewed dismissively compared to other languages of similar vintage like C or FORTRAN, because unlike those latter it did not come out of a "research-oriented context". However, as a matter of fact, neither C nor FORTRAN came out of academia; much like COBOL, they were developed for practical use as opposed to "research". ISTM that the perceived issues with COBOL must be explai…
C has roots of its usage in academia, the same way Unix does. I suspect, compared to other OSes of the era (Multics, MVS..), Unix doesn't require too much centralized control of (timeshared) operating system resources; for example the security model is extremely simple. So it was readily adopted in academia, because of this perceived user freedom (you just need a shell and you're good to go), and from there it spread…
Academia was crucial in the adoption of UNIX and C, because in the early days UNIX was free beer (AT&T tried to fix that afterwards), so a juicy alternative to paying for Multics, MVS...
That also made UNIX an ideal teaching device for OS programming classes versus the toy OSes developed by students.
Well, until AT&T forbade the circulation of UNIX V6 commented book.
https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...
Re: A Historical Perspective on COBOL (2020)
#10(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…
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.