So an appropriate (if uncommon) goal for the early 1980s was either to increase the productivity of existing developers by orders of magnitude, to increase the fraction of the population that could make good use of a computer, again by orders of magnitude, or both.
Given this goal, it is easy to see that the boutique programming languages were simply not up to the task. Yes, PASCAL introduced strong typing to mainstream developers, at least to those developers taking university courses. And yes, type-checking is valuable, but it is worth at best a few tens of percent, not orders of magnitude. And PASCAL's type checking did not come for free, given that PASCAL did not support compile-time initialization of variables, had very strange for-loop semantics, and had very limited library support. As a case in point, the limited library support could (and sometimes did) result in an order-of-magnitude disadvantage to PASCAL programmers compared to their C-language colleagues, courtesy of C's extensive libraries.
The other “fad” languages were in a similar situation: small advantages in some limited areas, large disadvantages in other areas.
The real programming language heroes of the 1980s “good” category are the spreadsheet, the presentation manager, and word-processing software. Some might argue that these are not real programming languages, but this misguided argument completely misses the point. These software artifacts, however you choose to classify them, were the things that made computers accessible to non-programmers. They changed the world, in ways that were at the time unimaginable.
Before the spreadsheet, financial analyses were carried out either on chalkboards or with pencil and paper. This work was slow, tedious, and error-prone. The spreadsheet, even in its earliest form, easily sped up such analyses by orders of magnitude. Another alternative in pre-spreadsheet days was to code up a COBOL program to do the analysis, but here the non-programmer could but propose a project and hope that the IT staff got around to implementing some approximation to it — some day. So the spreadsheet not only provided orders of magnitude improvements in productivity, it also opened computer usage to non-programmers, increasing the fraction of the population who could deal directly with a computer by many orders of magnitude.
Before the presentation manager, the dominant presentation media were 35mm slides and hand-written presentations on acetate foils. The 35mm slides used real physical film, which had to be processed, with turn-around times measured in days or even weeks. Hand-written acetate foils can actually be generated more quickly than the equivalent in, say, OpenOffice, but editing an existing OpenOffice presentation can be hugely faster than redrawing an acetate slide. And speaking as someone who lugged a week's worth of acetate slides (a stack that was many inches thick and not light weight) through all twenty-four time zones, I can personally attest to some very real advantages of the much-maligned presentation manager. Thus, the presentation manager also delivered orders of magnitude increases in productivity, and, just like the spreadsheet, greatly expanded the fraction of the population who could make good use of a computer.
To see the benefits conferred by the word processor, find an old
typewriter and try typing up a five-page report.
For extra credit, use neither eraseable bond nor white-out.
How many times did you have to start over with a clean sheet of paper?
I rest my case.
The spreadsheet, the presentation manager, and the word processor were certainly not cool, nor did they get existing developers or researchers excited. But it was the spreadsheet, the presentation manager, and the word processor that solved the 1980s software crisis.
And for those of you complaining that this is a trick question, rest assured that the question is in no way a trick. It is the answer that is the trick, a trick that we would be wise to apply to the current parallel-software crisis.