On 09/27/2014 08:10 AM, Paul Koning wrote:
But that was Dijkstra?s point. Reliability is not
helped by having
lots of features. Having 7 ways to do something is not better than
having one way. (This is why I stopped using Perl and use Python
instead ? ?there is more than one way to do it? is not a language
design principle I consider a recommendation.)
So what language would Dijkstra have used in 1960 to implement his BDP
application? COBOL was notable in taking business languages from
several vendors (e.g. COMTRAN, FLOW-MATIC) and coming up with a common
dialect.
COBOL was plagued, in the beginning, not primarily with issues of
language, but of "cheats", such as IBM's "ENTER LINKAGE" for the
S/360
or "ENTER AUTOCODER" for the earlier machines. IBM did nothing to
discourage this--indeed, with the initial S/360 COBOL implementations,
one had to resort of ENTER LINKAGE for ISAM files (I have the document
detailing this).
In, I think it was, COBOL 75, there was sufficient backlash toward
vendor additions/"features" to the language that it was mandated in the
standard that the default behavior of a compiler was to consider vendor
extensions and features as errors, unless explicitly enabled. I vividly
recall running the Navy Audit Tests before every new release.
When answering program trouble reports, I had a well-thumbed copy of the
CODASYL standard on my desk. It was very explicit in how things should
and must work. Very handy for citing chapter and verse when a
customer's complaint did not reflect reality.
Heck, Dijkstra's pet Pascal didn't even *have* I/O initially, much less
implementing ISAM. By then, of course, probably tens or hundreds of
millions of lines of COBOL had been written. I don't remember Dijkstra
offering to convert them to Pascal.
--Chuck