> 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.