Used it in my first few jobs starting 1970. Surprised this doesn't mention ALTER for changing the destination of GO TO statements. If you thought goto was bad, think about one which goes somewhere other than where it says it will!
I'll explain. Cobol is a simple language in the same way that Go is also a simple language. Even though they are very different of course, in both languages a single statement or even a small piece of code (like a single line) is easy to read and understand.
This is nice for beginners who are still struggling with basic concepts. It allows to understand code incrementally.
But that does not mean that whole programs are also (comparibly!) easy to read. No, it is the opposite. If two languages are equally well made, but one focusses on small parts being easy to understand while the other one focusses on being very expressive, then a well-versed developer will have a much easier time with the more complex language. But an inexperienced one will struggle and have a much higher learning curve.
It is really a tradeoff. Similar to archiving files. You can choose to compress them very small, but this will cost more CPU and time (requires complex algorithms in many cases, see video-compression and potentially multiple passes) but decrease filesize. You can also choose low compression but a simple and fast one-pass algorithm can be used here.
Neither is inherental good or bad and it explains why people call languages simple or easy and others disagree. Because they are really talking about two different aspects.
Thank you for clarifying, I don't think I'm entirely convinced though, a language can be both easy to read and provide a way to avoid that larger code-bases turn into spaghetti.
I don't think there needs to be any tradeoff in the language itself for this. There will be tradeoffs in the complexity of programs to avoid it, but that seems to be true no matter the language.
Of course, the languages that are both easy to get started with, and at the same time, powerful enough for large systems to be written, result in a lot of very terrible programs, not because they are _bad_languages_(tm) but because they're a perfect balance between ease-of-use, flexibility and power to expand.
> a language can be both easy to read and provide a way to avoid that larger code-bases turn into spaghetti.
"easy" is always relative, so compared to what? Compared to a language that isn't well crafted? Sure. And in practice, most languages could be optimized a lot. But that is not what I was talking about and thinking like that only distracts you from the bigger picture.
Not sure what the spaghetti code come from. Use sort of today module and no go to even when I started. The issue of cobol it is very long winded. Like Java today. You have to read a lot to understand what is going on. But if you treat it like writing a book (as it is English they are after), it is ok as business language. As the author note they do force a bit declarations and any business guy will force some standard.
I would not recommend it. But it is like comment like not use gun to a Roman solider. In their times they are quite ok.
Imagine you use c or even c++ for business operation of just file in and out (using tape …). String processing … good luck
The spaghetti code in COBOL comes from the very tight coupling between concerns: the model, view and controller are generally all in the same. You'll have embedded database queries, right next to form layout, right next to your actual code. While the language itself may be ANSI, the interfaces people use to actually display and store data are vendor specific.
The closest analogy would be if you had some crazy late-90s Perl that relied on custom database and terminal drivers.
There's not much of a bandaid you can put on this to "modernize it" other than a rewrite.
> The spaghetti code in COBOL comes from the very tight coupling between concerns
I thought the spaghetti code in COBOL came from liberal use of GOTOs (e.g. following the execution path of the code is like following the path of a single spaghetti noodle in a plate of spaghetti).
There's architectural spaghetti and there are lower levels of spaghetti.
COBOL introduced alternatives to unconditional jumps in the 60s. You can convert unconditional jumps to different control flow structures through static analysis. Plusfort does this for FORTRAN pretty well. I'm sure there's an equivalent tool for COBOL somewhere. The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
> There's architectural spaghetti and there are lower levels of spaghetti....
> The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
I'm not saying that's not a problem, just that it feels like it could be an anachronism to use "spaghetti code" to refer to that in the context of a COBOL program.
Honestly, I don't think I have used cygwin since WSL came out (and it was pretty common for me to use linux vms even before then).
The notable exception is that I indirectly use MSYS2 (which is effectively a fork of cygwin) as part of using git for windows. Git for Windows includes an msys2 environment so that the portions of git that are written as shell scripts or perl scripts, etc can run properly. While you can launch the "git bash" directly, and pre-wsl that could be useful, the MSYS is mostly there because Git for Window's git.exe will automatically launch subcommands in that environment.
I would guess that it does not use WSL or an actual Linux because it was written for use on Windows, and at a time when many of the Windows installations then in use were of a version that did not offer WSL.
Cygwin is extremely lightweight, it's basically just a library implementing the POSIX syscalls, and native win32 apps linked to it.
Since it's so lightweight, you can have, use, and throw away as many cygwin envs (folders) as you like.
It doesn't require any Windows subsystem, hypervisor, admin rights, Linux distribution or anything, and will even work on an XP machine should you need it.
To attempt to answer the second - I’ve heard the often-repeated “COBOL pays great!” statement isn’t actually true.
From what I recall (no personal experience), the pay is quite a bit less than big tech, with the downside of an antiquated language on the resume and nightmare codebases to deal with. Doesn’t sound like a good career move.
Don't "antiquated language" and "nightmare codebases" apply to the big tech too though? I mean I'm sure some of their code is modern but a lot was built 20 years ago by now (think PHP at FB, C++ at Google, Java sprinkled everywhere).
> To attempt to answer the second - I’ve heard the often-repeated “COBOL pays great!” statement isn’t actually true.
> From what I recall (no personal experience), the pay is quite a bit less than big tech, with the downside of an antiquated language on the resume and nightmare codebases to deal with. Doesn’t sound like a good career move.
FAANG salaries are kind of ridiculous, so using them as a base for a comparison is probably not going to lead to much insight.
Still, the common advice seems to be to learn COBOL for big salaries. In reality, it’s nowhere near what’s defined as “big salary” in software engineering, more like “totally average”.
I work for a company that uses COBOL still and have talked with many people that work in other mainframe shops. You are correct that the pay being great is generally not true.
The two exceptions are people with decades of experience that have the advantage of understanding the business logic they helped build during their time and the truly exceptional people out there that work as contractors for desperate companies unable to find people that can understand their systems.
So there is money in COBOL, but I don't think it's particularly accessible to anyone new. Maybe as more veterans retire, salary rates for new devs will go up. There is an interesting trade off between paying more to attract talent and taking the risk of migrating off a mainframe. COBOL is easy to teach, the hard part is maintaining the business logic that was built up over decades. Our parent company recently shut down their mainframe, but it took them nearly 7 years to complete that process. Many other companies have failed and wasted years and millions of dollars trying to migrate. It is massive challenge.
There are some schools in the USA that offered COBOL/Mainframe courses, read sometime ago on a news article that students found it attractive to enter some industry sectors.
Regarding pay my guess is that it's not great if you only program COBOL. Like other stacks you need to know about the operating system, the source control system, the pipelines, scripting (JCL), etc. COBOL it's easy to learn since it's a very simple language but the rest of the stack is hard because you don't have access to them.
> 2021 Median yearly salary (USD) - $52,340
> 2022 Median yearly salary (USD) - $75,592
I think when people talk about ATM transaction involving Cobol, it's more about the server software responding, not the one running on terminals.
Having said that, I wouldn't be too surprised if old green screen ATMs would have used COBOL. Ran on smaller computers and you could compile stuff with it.
Nowadays, I'd be surprised if it wouldn't just be your regular Java/.NET/C++ brouhaha. They should have phased out most ATMs running OS/2 by now, though.
Some early ATMs might have been effectively green screen terminals calling into CICS or IMS interface.
These days it's more likely that the COBOL is somewhere in the IMS transactions (IBM bragged sometime in last decade that ~80% of ATM transactions are implemented on top of IMS at some point).
IMS is a navigational (CODASYL) database system with iirc a form of application server - what you'd call today a NoSQL database :P - designed for Apollo project supply chain handling.
Why so verbose? In today’s languages and document editors you can just insert a <page break> or EOF.
But I can understand why back then in documents they’d have to write out things like “Period. End of story.” without actual periods and control characters
(for people wondering, I am parodying the article)
>I am fascinated by how this 70-year-old creature has kept many similarities to today’s stacks, for example with IF and SWITCH
If you like that, I recommend you take a look at a language called FORTRAN (2 years older than COBOL and still used). And if you enjoy legacy and good design still being alive, LISP (1 year older) will blow your mind.
There's a lot of jokes about 'old' languages but when you see the amount of churn with the new ones cough javascript cough then you appreciate how it's nice have something written once and for all. Plenty of FORTRAN still in the core of Numpy, doing core maths and being very good at it.
Ridiculous amounts of US weaponry are still dependant on JOVIAL, a slightly younger language whose claim to fame is adding what many people would now call "structs" to Algol.
Getting rid of it was one of the reasons for Ada mandate, but as usual exceptions made it hard (PATRIOT is reportedly heavily JOVIAL based and a shitshow to program)
Of course COBOL had comments. You put an asterisk at the start of the line, or in a particular column, depending on the compiler's extensions for doing away with line numbers. What the Stack Overflow link is saying is that it didn't have comments that could follow a statement on a line, but got them at roughly the same time C got C++-style // comments.
I only did a couple of short paid stints with the language, back in the 1980s, but from my memory of it the biggest problem with it was the huge number of reserved words. One project therefore mandated that every identifier start with "100-"! The problem with globals was real, but contemporaneous Pascal had a globals problem too. There was a mechanism to interpolate source code of procedures; since the language had been designed back in the days of batch jobs elapsed compilation time didn't matter.
COBOL programmers tended to be isolated from the wider programming world and from people with a formal background in computer science. I arrived at that project too late to prevent them making design decisions like firing up a new executable for each transaction (expensive on VAX/VMS, but at least it was in the same process) or storing passwords in cleartext. They just did it the way they'd done it 15 years before on the big iron. It was a case of "I wish you'd been here 6 months ago to tell us about that, but it's too late now", or perhaps they were just being polite to the hired help.
You could argue that whatever the business-oriented language had been, those same people would have made the same mistakes. At least with COBOL, the language was such that they could be domain experts, for example accountants.
Funny anecdote about this. I used to work on a relatively old (early 1980s) COBOL and PL/1 codebase. Code was obviously a mess, as most of the files were written by non devs, and hardly had any comments.
There was this one though, that started with something like "this code handles currency conversions, and the author is long gone now; no one understands it, but if you need to modify it, please be aware that you may break all the business logic the bank relies on".
Code was modified once, in the late 90s, to support some Euro and Y2K oddities. No one else dared to touch it afterwards.
But hardly anyone wrote very many comments in the early days because every comment was another punch card, with all the attendant problems that only grow the larger the deck grows.
The only thing that makes COBOL difficult is that it is very _very_ opinionated. A good IDE actually takes quite a bit of the pain away.
At the end of the day, it’s just a thin layer over assembly.
I’m 2012-13 I wrote a Java -> COBOL bridge to directly invoke ‘MainFrame transactions’ from a JVM. Unlike the IBM solution, we never did anything with XML or text parsing and did everything using bit and integer manipulation. Java types and fields were annotated with their COBOL Record equivalents. Initially we used reflection which was fast but being Cowboys we made it even faster by using CGLib and writing custom classes at run time that could be JIT compiled.
This process was absolutely fascinating and it really took my career to the next level because a deeply understood what was happening in memory in both languages afterwards. It saved the company millions in license fees and we went from latency measured in seconds to below 8ms to invoke code.
The problem with this article is the same as with every article about COBOL, FORTRAN, RPG, Mainframes etc:
The assumption that it is only 50+ year old legacy code running on dependable
but obsolete hardware, untouched by human hands in decades is wrong.
In reality, much of it is new. COBOL shops still develop new software. IBM still makes brand new mainframes. The developers are not all old men in suits, they look pretty much like C++ or Java (or any other established tech) programmers: all ages. That may look old to you because you're biased to think of programmers as males aged 20 to 35.
By the way, I'm not saying it doesn't suck. It's not something I ever intend to do in my life again.
I know RPG did that. I can't tell you if all programs do that, probably not today, but that was the origin. Keep in mind that at the time, all your data was on tape, punch cards or disk, you only had a few kb of RAM.
IBM still churns out new releases of the programming language, where they keep tacking on support for all the things programmers of today want to do.
Back in '02 when I was learning COBOL in school, the absolute worst sin you could commit was forgetting that STOP RUN or the period following it. If you did that, the mainframe would crash, and nobody could continue working on their assignments until somebody had called the operator and gotten them to reset the mainframe. The night before assignments were due, they had to pay someone overtime to stay up and be ready to hit the switch at any time because of this. And, of course, if you hadn't saved in a while, you lost your work.
At some point, we either found or were given a local IDE, which we then used to write code that we tested on the mainframe afterwards, and it was a game-changer. But also, the IDE used a later and better version of COBOL than the mainframe, so sometimes you'd write an instruction that worked locally and blew up on the mainframe, and you'd have to rewrite your whole everything to get around missing basic control flow structures.
The article notes that, "before 2002, COBOL didn’t support comments" and later observes, "It’s also very clear and stable, and a non-technical person can easily read the code and figure out what it does".
The inventors of COBOL were keen on the "non-technical person" being able to understand the code. What they may not have valued or understood at the time was the need for future people "to understand who, why and how someone made that choice in the 60s". Largely, it was simply a matter of optimizing for space on the computer's storage media. In other words, saving punch cards. It was the practice at the time to keep the documentation, printed on paper, and the cards together.
Why create all those punch cards that the compiler is going to ignore, when you can simply use regular paper? Card punches and readers were finicky. Readers could only read so fast, and while they got faster and more reliable over time, in no universe were they going to match even a slow medium like 9-track tape.
There have been COBOL IDEs since at least back when I learned it in college, 20 years ago, which will improve the lives of any COBOL developer, but I imagine many places that are still stuck using COBOL are likely stuck on an earlier version that doesn't support OOP. If they never got past COBOL-80, they didn't even have a switch statement!
So a young developer inexperienced with COBOL and old computers tries to set up his modern days IDE for it, "laughed hard" (sic) judging it by modern standards, then publishes a long article to share his misconceptions.
Honestly, his "surreal" experience isn't caused by COBOL but his inability to understand a technology in its age and context. Why do we keep sharing content so little informed?
68 comments
[ 315 ms ] story [ 1445 ms ] threadAnd without comments as the article says, you couldn't even document what it was for or where it gets changed.
I do take issue with the simultaneous statements that spaghetti code is unavoidable, and programs written in the language are easy to read.
It's either one, or the other, they're mutually exclusive.
This is nice for beginners who are still struggling with basic concepts. It allows to understand code incrementally.
But that does not mean that whole programs are also (comparibly!) easy to read. No, it is the opposite. If two languages are equally well made, but one focusses on small parts being easy to understand while the other one focusses on being very expressive, then a well-versed developer will have a much easier time with the more complex language. But an inexperienced one will struggle and have a much higher learning curve.
It is really a tradeoff. Similar to archiving files. You can choose to compress them very small, but this will cost more CPU and time (requires complex algorithms in many cases, see video-compression and potentially multiple passes) but decrease filesize. You can also choose low compression but a simple and fast one-pass algorithm can be used here.
Neither is inherental good or bad and it explains why people call languages simple or easy and others disagree. Because they are really talking about two different aspects.
I don't think there needs to be any tradeoff in the language itself for this. There will be tradeoffs in the complexity of programs to avoid it, but that seems to be true no matter the language.
Of course, the languages that are both easy to get started with, and at the same time, powerful enough for large systems to be written, result in a lot of very terrible programs, not because they are _bad_languages_(tm) but because they're a perfect balance between ease-of-use, flexibility and power to expand.
"easy" is always relative, so compared to what? Compared to a language that isn't well crafted? Sure. And in practice, most languages could be optimized a lot. But that is not what I was talking about and thinking like that only distracts you from the bigger picture.
I would not recommend it. But it is like comment like not use gun to a Roman solider. In their times they are quite ok.
Imagine you use c or even c++ for business operation of just file in and out (using tape …). String processing … good luck
The closest analogy would be if you had some crazy late-90s Perl that relied on custom database and terminal drivers.
There's not much of a bandaid you can put on this to "modernize it" other than a rewrite.
I thought the spaghetti code in COBOL came from liberal use of GOTOs (e.g. following the execution path of the code is like following the path of a single spaghetti noodle in a plate of spaghetti).
COBOL introduced alternatives to unconditional jumps in the 60s. You can convert unconditional jumps to different control flow structures through static analysis. Plusfort does this for FORTRAN pretty well. I'm sure there's an equivalent tool for COBOL somewhere. The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
> The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
I'm not saying that's not a problem, just that it feels like it could be an anachronism to use "spaghetti code" to refer to that in the context of a COBOL program.
Why do people still use cygwin, and not WSL or an actual linux?
A. Cygwin works and has been around for a long time. B. Cygwin programs are native windows procs.
The notable exception is that I indirectly use MSYS2 (which is effectively a fork of cygwin) as part of using git for windows. Git for Windows includes an msys2 environment so that the portions of git that are written as shell scripts or perl scripts, etc can run properly. While you can launch the "git bash" directly, and pre-wsl that could be useful, the MSYS is mostly there because Git for Window's git.exe will automatically launch subcommands in that environment.
Since it's so lightweight, you can have, use, and throw away as many cygwin envs (folders) as you like.
It doesn't require any Windows subsystem, hypervisor, admin rights, Linux distribution or anything, and will even work on an XP machine should you need it.
Finally: much less bloat to run and store.
From what I recall (no personal experience), the pay is quite a bit less than big tech, with the downside of an antiquated language on the resume and nightmare codebases to deal with. Doesn’t sound like a good career move.
> From what I recall (no personal experience), the pay is quite a bit less than big tech, with the downside of an antiquated language on the resume and nightmare codebases to deal with. Doesn’t sound like a good career move.
FAANG salaries are kind of ridiculous, so using them as a base for a comparison is probably not going to lead to much insight.
The two exceptions are people with decades of experience that have the advantage of understanding the business logic they helped build during their time and the truly exceptional people out there that work as contractors for desperate companies unable to find people that can understand their systems.
So there is money in COBOL, but I don't think it's particularly accessible to anyone new. Maybe as more veterans retire, salary rates for new devs will go up. There is an interesting trade off between paying more to attract talent and taking the risk of migrating off a mainframe. COBOL is easy to teach, the hard part is maintaining the business logic that was built up over decades. Our parent company recently shut down their mainframe, but it took them nearly 7 years to complete that process. Many other companies have failed and wasted years and millions of dollars trying to migrate. It is massive challenge.
Also, mainframe has one of the oldest "meetup" groups which also supports new comers https://en.wikipedia.org/wiki/SHARE_(computing)
Regarding pay my guess is that it's not great if you only program COBOL. Like other stacks you need to know about the operating system, the source control system, the pipelines, scripting (JCL), etc. COBOL it's easy to learn since it's a very simple language but the rest of the stack is hard because you don't have access to them.
> 2021 Median yearly salary (USD) - $52,340 > 2022 Median yearly salary (USD) - $75,592
Source: https://survey.stackoverflow.co/2022/#technology-top-paying-...
Having said that, I wouldn't be too surprised if old green screen ATMs would have used COBOL. Ran on smaller computers and you could compile stuff with it.
Nowadays, I'd be surprised if it wouldn't just be your regular Java/.NET/C++ brouhaha. They should have phased out most ATMs running OS/2 by now, though.
These days it's more likely that the COBOL is somewhere in the IMS transactions (IBM bragged sometime in last decade that ~80% of ATM transactions are implemented on top of IMS at some point).
IMS is a navigational (CODASYL) database system with iirc a form of application server - what you'd call today a NoSQL database :P - designed for Apollo project supply chain handling.
A federal agency had an IBM Mainframe and X.25 9600 baud satellite connections to local agencies all around the country (more than 200).
Every day they synchronize data between agencies sending plain txt tabular data. They were charged by amount of data they transferred.
We implemented a basic compression algorithm in COBOL because IBM C package was not available and expensive. We also implemented it in REXX [1].
The compression was very successful but the CPU went very high and affected other processes in the mainframe.
At the end the agency didn't implement it. End of story.
[1] https://en.wikipedia.org/wiki/Rexx and don't miss https://en.wikipedia.org/wiki/ARexx
Why so verbose? In today’s languages and document editors you can just insert a <page break> or EOF.
But I can understand why back then in documents they’d have to write out things like “Period. End of story.” without actual periods and control characters
(for people wondering, I am parodying the article)
Because it is in COBOL ;-)
Lets not. It's old and compiled so comparing it so two scripting languages with massive runtimes is silly.
If you like that, I recommend you take a look at a language called FORTRAN (2 years older than COBOL and still used). And if you enjoy legacy and good design still being alive, LISP (1 year older) will blow your mind.
Getting rid of it was one of the reasons for Ada mandate, but as usual exceptions made it hard (PATRIOT is reportedly heavily JOVIAL based and a shitshow to program)
My guess is social-media induced hyperbole. "A peek at COBOL," just doesn't have the same potential to bait clicks.
I only did a couple of short paid stints with the language, back in the 1980s, but from my memory of it the biggest problem with it was the huge number of reserved words. One project therefore mandated that every identifier start with "100-"! The problem with globals was real, but contemporaneous Pascal had a globals problem too. There was a mechanism to interpolate source code of procedures; since the language had been designed back in the days of batch jobs elapsed compilation time didn't matter.
COBOL programmers tended to be isolated from the wider programming world and from people with a formal background in computer science. I arrived at that project too late to prevent them making design decisions like firing up a new executable for each transaction (expensive on VAX/VMS, but at least it was in the same process) or storing passwords in cleartext. They just did it the way they'd done it 15 years before on the big iron. It was a case of "I wish you'd been here 6 months ago to tell us about that, but it's too late now", or perhaps they were just being polite to the hired help.
You could argue that whatever the business-oriented language had been, those same people would have made the same mistakes. At least with COBOL, the language was such that they could be domain experts, for example accountants.
Funny anecdote about this. I used to work on a relatively old (early 1980s) COBOL and PL/1 codebase. Code was obviously a mess, as most of the files were written by non devs, and hardly had any comments.
There was this one though, that started with something like "this code handles currency conversions, and the author is long gone now; no one understands it, but if you need to modify it, please be aware that you may break all the business logic the bank relies on".
Code was modified once, in the late 90s, to support some Euro and Y2K oddities. No one else dared to touch it afterwards.
At the end of the day, it’s just a thin layer over assembly.
I’m 2012-13 I wrote a Java -> COBOL bridge to directly invoke ‘MainFrame transactions’ from a JVM. Unlike the IBM solution, we never did anything with XML or text parsing and did everything using bit and integer manipulation. Java types and fields were annotated with their COBOL Record equivalents. Initially we used reflection which was fast but being Cowboys we made it even faster by using CGLib and writing custom classes at run time that could be JIT compiled.
This process was absolutely fascinating and it really took my career to the next level because a deeply understood what was happening in memory in both languages afterwards. It saved the company millions in license fees and we went from latency measured in seconds to below 8ms to invoke code.
By the way, I'm not saying it doesn't suck. It's not something I ever intend to do in my life again.
How computer-ish. What else is it going to do at the end of the program?
I'd find it hard to work in a programming language that's all upper case and shouting.
IBM still churns out new releases of the programming language, where they keep tacking on support for all the things programmers of today want to do.
Here's a story for you.
Back in '02 when I was learning COBOL in school, the absolute worst sin you could commit was forgetting that STOP RUN or the period following it. If you did that, the mainframe would crash, and nobody could continue working on their assignments until somebody had called the operator and gotten them to reset the mainframe. The night before assignments were due, they had to pay someone overtime to stay up and be ready to hit the switch at any time because of this. And, of course, if you hadn't saved in a while, you lost your work.
At some point, we either found or were given a local IDE, which we then used to write code that we tested on the mainframe afterwards, and it was a game-changer. But also, the IDE used a later and better version of COBOL than the mainframe, so sometimes you'd write an instruction that worked locally and blew up on the mainframe, and you'd have to rewrite your whole everything to get around missing basic control flow structures.
The inventors of COBOL were keen on the "non-technical person" being able to understand the code. What they may not have valued or understood at the time was the need for future people "to understand who, why and how someone made that choice in the 60s". Largely, it was simply a matter of optimizing for space on the computer's storage media. In other words, saving punch cards. It was the practice at the time to keep the documentation, printed on paper, and the cards together.
Why create all those punch cards that the compiler is going to ignore, when you can simply use regular paper? Card punches and readers were finicky. Readers could only read so fast, and while they got faster and more reliable over time, in no universe were they going to match even a slow medium like 9-track tape.
https://www.microfocus.com/en-us/products/visual-cobol/overv...
Think positive, at least it isn't RPG, https://en.wikipedia.org/wiki/IBM_RPG
Honestly, his "surreal" experience isn't caused by COBOL but his inability to understand a technology in its age and context. Why do we keep sharing content so little informed?