> Take, for example, the Job Control Language (JCL) designed for IBM’s OS/360 in 1965, described by Brooks [2010, pp 169–173] as “The Worst Computer Language Ever.”
I disagree with this significantly. It misunderstands the problem JCL was actually trying to solve. These computers had less than 24MB of ram, as 24MB was all you could _address_ anyways, they had no paging, a very limited "memory protection key" access control mechanism, and hundreds if not thousands of jobs being submitted to it.
The "language" fits it's problem domain and absolutely nothing else. It allows you to write mostly generic programs and then string them together in advanced ways, which all mostly center around "data set definitions" which are important due to the odd way that mainframes arrange files into "data set." It allows you to string jobs together, manage failures and restarts, and entirely handles output and print spooling for you.
Data sets become such a pain because there's really no "driver model" on a mainframe. You use "channel programs" to interact with hardware. So your channel programs somewhat had to understand the physical drive layout (cylinders/tracks) in order to use them. In the beginning they were often fixed length records, so every line was 80 characters, because they were originally just a convenience to hold copies of punch cards on random access. Previously tape was used extensively.
JCL provides very useful functions inside of this somewhat spartan environment. It was also born out of the IBM/NASA parnership in the 1960s. To this day the JES system which handles JCL cards produces messages starting with "HASP" which is short for "Houston Automatic Spooling Priority" Program.
It's actually kinda beautiful once you spend a few minutes with it.
> one that is so hard to learn that people copied working scripts blindly
That's not really why they are copied. They are copied because they are known to work, and in most cases, you're simply changing the data set definitions and possibly some arguments for your purposes. You're effectively just changing the command line switches. Since this was the only convenient way to run jobs and get output, all the switches are at the top, and all the ugly is at the bottom. They're designed intentionally this way.
The rest of the complexity mostly boils down to TSO (time sharing option, the shell system) or other components having unusual and unfriendly syntax. So you get a "job card" with all the complicated TSO stuff worked out, with some very nice data set and argument definitions that are easy to change, and on a main frame you can submit jobs straight from the editor, so this is all a very natural workflow for any TSO user. Copy, Edit, Submit.
Oh, and because of JCLs oddball line prefix syntax, you can straight up embed it inside your COBOL or FORTRAN programs and submit it to the job system directly.
> “The biggest flaw of all was that JCL is indeed a programming language, but it as not perceived as such by its designers”
This biggest flaw of mainframe criticism is not understanding the platform correctly. I always encourage people to get MVS TK5 and run it on hercules. It's an absolute blast and reveals an entirely ignored and often forgotten side of computing. If you have any nostalgia for the 90s you can get lost in what the enterprise created.
So you are saying that Brooks, who was the manager of the System/360 project, for which JCL was created, and who calls JCL "the worst computer language ever", just doesn't understand mainframes and the contemporary environment they existed in and the problems they were solving?
I mean, he literally says "It was developed under my supervision; there is blame enough to go around among all the supervisory levels," so I'd think he knows what was actually going on during its development.
> just doesn't understand mainframes and the contemporary environment they existed in and the problems they were solving?
Yes, I am saying exactly that. He was a hardware designer who essentially ended up on the OS/360 project as a manager.
> so I'd think he knows what was actually going on during its development.
Almost no one who uses JCL would describe it or think of it as a "language." Mr Brook's entire criticism is founded in his historical author's view and not in a practical end users point of view.
> Almost no one who uses JCL would describe it or think of it as a "language."
That's an odd statement. JCL stands for "Job Control Language", why would it not be thought of as a language? I certainly did when I was using it (two decades ago or so, now). If you mean it's not a programming language, well, it is. It's just a particularly bad one. In the same way that YAML config files are not a good programming language, even if they're an effective description language. That doesn't stop Ansible and the rest from turning them into terrible programming languages.
Not in the context that this article is attempting to establish. It's a tool, with a syntax, do you think of command line programs and switches as "mini languages?" Would you write anything other than batch requests in JCL?
It's playing fast and loose with what a "language" means and it's presented in such a way as to sell books and not inform an audience.
> It's a tool, with a syntax, do you think of command line programs and switches as "mini languages?"
Some, certainly. find, for example, contains an awkward programming language in its set of command line arguments. Most others are simple enough I think a case could be made for treating them as mini languages but I wouldn't bother arguing for it.
I probably wouldn't write anything other than batch requests in JCL but that's because that's its purpose, it's a scripting language for batch processing. That doesn't make it not a programming language, it makes it a specialized programming language.
Is your issue that you are only considering things to be programming languages if they are general purpose programming languages? If so, we'll have to agree to disagree. Your view is too narrow for me, and mine too broad for you.
This is probably the more liberating and insightful paper I've ever read on programming (close 2nd: "Teach Yourself Programming in 10 years"). So many things I already knew from experience, but had never seen been addressed so clearly and _embraced_ at the same time.
It might as well be! Code and configuration don’t have a practical difference in their potential impact on running systems; both are equally capable of causing security breaches or outages.
Yes. ini files are simple programming languages. The application that processes it is acting as the interpreter, its behavior changes based on what's described in the ini file.
I disagree with this significantly. It misunderstands the problem JCL was actually trying to solve. These computers had less than 24MB of ram, as 24MB was all you could _address_ anyways, they had no paging, a very limited "memory protection key" access control mechanism, and hundreds if not thousands of jobs being submitted to it.
The "language" fits it's problem domain and absolutely nothing else. It allows you to write mostly generic programs and then string them together in advanced ways, which all mostly center around "data set definitions" which are important due to the odd way that mainframes arrange files into "data set." It allows you to string jobs together, manage failures and restarts, and entirely handles output and print spooling for you.
Data sets become such a pain because there's really no "driver model" on a mainframe. You use "channel programs" to interact with hardware. So your channel programs somewhat had to understand the physical drive layout (cylinders/tracks) in order to use them. In the beginning they were often fixed length records, so every line was 80 characters, because they were originally just a convenience to hold copies of punch cards on random access. Previously tape was used extensively.
JCL provides very useful functions inside of this somewhat spartan environment. It was also born out of the IBM/NASA parnership in the 1960s. To this day the JES system which handles JCL cards produces messages starting with "HASP" which is short for "Houston Automatic Spooling Priority" Program.
It's actually kinda beautiful once you spend a few minutes with it.
> one that is so hard to learn that people copied working scripts blindly
That's not really why they are copied. They are copied because they are known to work, and in most cases, you're simply changing the data set definitions and possibly some arguments for your purposes. You're effectively just changing the command line switches. Since this was the only convenient way to run jobs and get output, all the switches are at the top, and all the ugly is at the bottom. They're designed intentionally this way.
The rest of the complexity mostly boils down to TSO (time sharing option, the shell system) or other components having unusual and unfriendly syntax. So you get a "job card" with all the complicated TSO stuff worked out, with some very nice data set and argument definitions that are easy to change, and on a main frame you can submit jobs straight from the editor, so this is all a very natural workflow for any TSO user. Copy, Edit, Submit.
Oh, and because of JCLs oddball line prefix syntax, you can straight up embed it inside your COBOL or FORTRAN programs and submit it to the job system directly.
> “The biggest flaw of all was that JCL is indeed a programming language, but it as not perceived as such by its designers”
This biggest flaw of mainframe criticism is not understanding the platform correctly. I always encourage people to get MVS TK5 and run it on hercules. It's an absolute blast and reveals an entirely ignored and often forgotten side of computing. If you have any nostalgia for the 90s you can get lost in what the enterprise created.