COBOL was my first professional programming language.
We wrote the code with a pencil, on coding sheets. The team leader checked it, and once it was deemed OK, we could type it in on a terminal.
It was a horrible language. The article speaks of code that "reads like a novel"; I swear I never read COBOL code that was easy to read. The problem was that COBOL doesn't lend itself to expressing structure. Combined with the fact that we were under commercial pressure to ship code, we shipped a lot of spaghetti code.
The idea that COBOL code is "easy to maintain" is nonsense. Any non-trivial COBOL program that is easy to read and maintain is going to be harder to write than an equivalent program in (say) Pascal, PL1 or ALGOL.
I worked for Burroughs; one of the super-powers of the Burroughs systems was hardware BCD arithmetic. It allowed a COBOL programmer to declare numeric variables with any specified number of decimal digits, and perform arithmetic on them with exact precision, easily. This is necessary when handling currencies, for example. Also, a hex dump of a BCD variable is precisely it's decimal value - BCD made it easy to debug.
It is said that COBOL is unsuited to systems programming. This is true; but it's not impossible. I was lucky enough to be sent on an "advanced COBOL course", in which I learned that the Burroughs COBOL compiler had seven passes; and that you could stop it during the later passes, and edit the intermediate code, before resuming the remaining passes. This meant that you could do things like access registers and IO ports. It blew my mind (but I never made use of those learnings!)
For many years, I denied that I had ever learned COBOL, for fear of being marked-down as an old fogey. Now I'm retired, I am an old fogey, and I don't give a tinker's cuss.
IBM mainframes also do/did hardware BCD arithmetic, starting with System/360.
And as for COBOL not lending itself to structure, how did Structured COBOL exist, then? I wrote lots of COBOL without a single GO TO anywhere in the code.
I'd wager the version of COBOL GP used was older. I learned COBOL in the 90s on a personal PC, and it allowed structured programs then. No spaghetti code needed, just PERFORMs and strategically placed periods. Even a program with GOTOs could be made be structured.
Well, what I was using was called Burroughs COBOL. I was using it on minicomputers, but it was basically the same COBOL that ran on the big Burroughs mainframes. Mainframes needed to maintain backward compatibility, so I guess the COBOL I was using was 1st-generation.
I gave up COBOL before I ever encountered any Structured COBOL. Around that time I performed psychological repression of all memory I had of the language, or even that I'd used it.
It has taken years of programming-language therapy for me to start to recover these memories.
(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.
> 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.
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.
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.
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.
> 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.
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.
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.
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.
I remember growing up in the 80s and picking up disdain for COBOL because it was verbose. But then,
1. I recently found out that COBOL can calculate numerics to a degree of precision greater than most languages and libraries. It was a PITA to do monetary calculations right and it is built into the core of COBOL.
2. Reading the sample COBOL code, I realized though I can’t scan it fast, it is structured in a way that is not much different than reading or writing SQL.
3. Having written Ruby for 10 years, and spending a lot of time with DSLs and business domain languages, the aims of COBOL is really not that much different.
4. Having taken the long path through learning the design philosophy of Smalltalk, Christopher Alexander, sandstorm.io, Free Software, as well as my evolving thoughts on “regenerative technologies”, I am coming to the conclusion that it is important for end users to be able modify their computing environment for use in their local community. As such, COBOL may be a good case study for designing pattern languages.
>> A global pandemic in which more people than ever before are applying for unemployment is a situation that COBOL systems were never designed to handle, because a global catastrophe on this scale was never supposed to happen. And yet, even in the midst of this crisis, COBOL systems didn’t actually break down. Although New Jersey’s governor issued his desperate plea for COBOL programmers, later investigations revealed that it was the website through which people filed claims, written in the comparatively much newer programming language Java, that was responsible for the errors, breakdowns, and slowdowns. The backend system that processed those claims—the one written in COBOL—hadn’t been to blame at all.
One can bet good money on the expectation that the mainframes will be the last component of a system to crash and burn. Though to be fair that's not to do with COBOL, per se, it's just that mainframes are rock solid.
This 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.
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..
Lets chalk it up to different corporate cultures then. Copybooks around here have so much redefines that the smallest mistake causes data corruption. Also, theres not a week going by without someone running out of numbers.
Article acts like having a 'richer' language approximating English makes it easier or more approachable, but whenever I've tried such languages I've found them harder. A programming language with simple and more orthogonal syntax like C is much easier to learn and reason about, than a language where you learn so many different verbs/constructs like COBOL or Ada.
And I think that -- depending on the problem -- you want a more succinct language to express the problem in. Maths is a good example: maths would be far harder if we described everything in plain English without ever resorting to symbolic maths. Formulaic maths allows us to focus more on the structure and meaning rather than the encoding.
> Article acts like having a 'richer' language approximating English makes it easier or more approachable, but whenever I've tried such languages I've found them harder.
You're not the target audience. Grace Hopper explained it:
“I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.”
The goal was to give senior management the illusion of understanding what their hirelings were doing.
Very interesting, and I have a lot of respect for Grace Hopper personally. I think tech that's meant to look 'correct' to the right people is often worse off for it, though. I've got no interest in appealing to the people that won't even bother trying to look at it if it reminds them of maths or uses something other than plain English, but it has a place I suppose. I just think the posted article overestimates its scope.
I am, too. I (and, I assume, other professional programmers) want sharply-defined primitives/keywords/operators. Vagueness really gets in our way. And the problem is that English words don't have the kind of precise definitions that we need.
But COBOL wasn't built for us. The design goal of COBOL was to make professional programmers obsolete - to make it so anyone could program. (Epic fail on that design goal - COBOL was once the most common language used by professional programmers.) For the intended users, the "using ordinary words" was a feature, not a bug. But the actual users and the intended users are different people, and the English-like syntax doesn't work for the actual users.
I have a low opinion of it! And I'm not in a tiny minority there. There have been other query languages that seemed better to me, but SQL won. SQL's not nearly as wordy as COBOL though, if you want to calculate tax in SQL you're going to write a formula. I think there's a time and place for different styles of languages, for a general purpose (or even business-oriented) language I think it should have a relatively simple and succinct syntax. I just think a programming language that's more consistent and mechanical is easier for most people to grok, and I know a ton of programmers that like to tell everyone that they "sucked at maths, you don't need to be good at maths to program", the syntax didn't put them off.
I haven't written a Cobol program since the 1980s, and I am hopeful I never will. Still, Cobol had many significant advances.
1. It popularized the notion of program portability, in that a Cobol program was expected to run, nearly unchanged, on any machine with a Cobol compiler.
2. It popularized the notion of data portability, in that DISPLAY data (though not COMPUTATIONAL data) should be the same, and produce the same results, on machines of disparate architectures.
3. It popularized record data types.
4. It emphasized the idea of program readability, even though we would now (I hope) reject “pseudo-English” as a solution.
The fact that it fell (far!) short of these ideals should not blind us to Cobol's significant contribution to programming languages.
At least a dozen state unemployment systems still run on this sixty-one-year-old language, including ones that help administer funds of a billion dollars or more in California, Colorado, and New Jersey. When the deluge of unemployment claims hit, the havoc it seemed to wreak on COBOL systems was so widespread that many states apparently didn’t have enough programmers to repair the damage; the governor of New Jersey even publicly pleaded for the help of volunteers who knew the language.
The 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.
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.
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.
The article dismisses the criticism against COBOL with an argument akin to "mathematicians use those funny symbols because they like to feel superior to everybody else."
We wrote the code with a pencil, on coding sheets. The team leader checked it, and once it was deemed OK, we could type it in on a terminal.
It was a horrible language. The article speaks of code that "reads like a novel"; I swear I never read COBOL code that was easy to read. The problem was that COBOL doesn't lend itself to expressing structure. Combined with the fact that we were under commercial pressure to ship code, we shipped a lot of spaghetti code.
The idea that COBOL code is "easy to maintain" is nonsense. Any non-trivial COBOL program that is easy to read and maintain is going to be harder to write than an equivalent program in (say) Pascal, PL1 or ALGOL.
I worked for Burroughs; one of the super-powers of the Burroughs systems was hardware BCD arithmetic. It allowed a COBOL programmer to declare numeric variables with any specified number of decimal digits, and perform arithmetic on them with exact precision, easily. This is necessary when handling currencies, for example. Also, a hex dump of a BCD variable is precisely it's decimal value - BCD made it easy to debug.
It is said that COBOL is unsuited to systems programming. This is true; but it's not impossible. I was lucky enough to be sent on an "advanced COBOL course", in which I learned that the Burroughs COBOL compiler had seven passes; and that you could stop it during the later passes, and edit the intermediate code, before resuming the remaining passes. This meant that you could do things like access registers and IO ports. It blew my mind (but I never made use of those learnings!)
For many years, I denied that I had ever learned COBOL, for fear of being marked-down as an old fogey. Now I'm retired, I am an old fogey, and I don't give a tinker's cuss.
And as for COBOL not lending itself to structure, how did Structured COBOL exist, then? I wrote lots of COBOL without a single GO TO anywhere in the code.
I gave up COBOL before I ever encountered any Structured COBOL. Around that time I performed psychological repression of all memory I had of the language, or even that I'd used it.
It has taken years of programming-language therapy for me to start to recover these memories.
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.
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.
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.
1. No unnecessary periods in the code
2. Required periods (ending paragraphs and if/then/else) go on a line by themselves
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.
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.
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.
1. I recently found out that COBOL can calculate numerics to a degree of precision greater than most languages and libraries. It was a PITA to do monetary calculations right and it is built into the core of COBOL.
2. Reading the sample COBOL code, I realized though I can’t scan it fast, it is structured in a way that is not much different than reading or writing SQL.
3. Having written Ruby for 10 years, and spending a lot of time with DSLs and business domain languages, the aims of COBOL is really not that much different.
4. Having taken the long path through learning the design philosophy of Smalltalk, Christopher Alexander, sandstorm.io, Free Software, as well as my evolving thoughts on “regenerative technologies”, I am coming to the conclusion that it is important for end users to be able modify their computing environment for use in their local community. As such, COBOL may be a good case study for designing pattern languages.
One can bet good money on the expectation that the mainframes will be the last component of a system to crash and burn. Though to be fair that's not to do with COBOL, per se, it's just that mainframes are rock solid.
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.
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..
And I think that -- depending on the problem -- you want a more succinct language to express the problem in. Maths is a good example: maths would be far harder if we described everything in plain English without ever resorting to symbolic maths. Formulaic maths allows us to focus more on the structure and meaning rather than the encoding.
You're not the target audience. Grace Hopper explained it:
“I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.”
The goal was to give senior management the illusion of understanding what their hirelings were doing.
I am, too. I (and, I assume, other professional programmers) want sharply-defined primitives/keywords/operators. Vagueness really gets in our way. And the problem is that English words don't have the kind of precise definitions that we need.
But COBOL wasn't built for us. The design goal of COBOL was to make professional programmers obsolete - to make it so anyone could program. (Epic fail on that design goal - COBOL was once the most common language used by professional programmers.) For the intended users, the "using ordinary words" was a feature, not a bug. But the actual users and the intended users are different people, and the English-like syntax doesn't work for the actual users.
1. It popularized the notion of program portability, in that a Cobol program was expected to run, nearly unchanged, on any machine with a Cobol compiler.
2. It popularized the notion of data portability, in that DISPLAY data (though not COMPUTATIONAL data) should be the same, and produce the same results, on machines of disparate architectures.
3. It popularized record data types.
4. It emphasized the idea of program readability, even though we would now (I hope) reject “pseudo-English” as a solution.
The fact that it fell (far!) short of these ideals should not blind us to Cobol's significant contribution to programming languages.
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.
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...
Other than it was probably great having an OS where LISP had the spotlight alongside Assembly.