HLLs, which I prefer to call statement-level procedural languages (SLPLs) have
their uses, particularly for investigational, throwaway routines and report
preparation.
Much depends upon how an SLPL is taught and used. I write a lot of throwaway
PL/I; and when I do I write it much the way I write assembly language, with
heavy use of lists, pointers, pointers to pointers, DSECTs (based structures)
and the like; but I have seen many PL/I procedures that are best described as a
species of 1970s COBOL with semicolons, move-oriented compile-time bound junk.
Or again, I have never seen a discussion of the C switch statement that makes
clear what it really does, presumably because any such treatment would be 1)
machine-dependent in detail and 2) largely unintelligible to readers who knew
no assembly language. In the upshot switch statements and their DBCS
analogues, which are easy to construct in C, are too little used by C
programmers.
Algorithmic performance can and should initially be approached in largely
mathematical terms, but the advantages of an optimal algorithm can be and very
often are vitiated by a clumsy, inadequate implementation or by the vagaries of
compiled code.
The other objection to SLPLs is of course their insularity. Each of them
embodies its designers' peculiar notions of what is meaningful, good and
proper. Pascal fouled the nest. Like NEWSPEAK it attempted to prevent the
use of notionally bad practices by omitting to support the facilities needed to
employ them. (GOTOs lend themselves to abuse by novices; let's therefore
abolish GOTOs, etc., etc.).
The HLASM is not of course entirely culture-free, but it is not nanny-like, and
this is one of its greatest merits. It is also the only vehicle I have found
for teaching novice programmers how von Neumann machines work, and a knowledge
of machine architectures is a sine quo non for would be programmers.
Omitted, all the voyage of their life is bound in shallows and in miseries.
John Gilmore Ashland, MA 01721-1817 USA
