Hallo again Benct —
Dijkstra was a great theoretician, and in principle it is of course
right that the spec/documentation should dictate the behavior, but
as we all know there is usually, for practical reasons, more or less
distance between theory and practice, and in practice a piece of
software does what the code tells it to do, no more no less.
Personally I hate it when the spec/documentation describes some
feature only to be told that it is "not (yet) implemented", yet
partial or divergent implementations are quite common, and at the
end of the day a partial implementation is usually better than no
implementation at all. I am myself involved in a project which has
several implementations for different languages and it is very hard
to keep them all in synch, not least because the different
implementations depend on different libraries which dictate how and
if things can be done more or less easily. In practice one
implementation is ahead of the other two while another is more or
less stalled. No fun but a fact of life, especially in a volunteer
project where time is limited.
Dijkstra was indeed a /very/ great theoretician, and I think that the
IT world is a far poorer place not only for his passing but for the
passing of the generation of computer scientists that he epitomised.
Dijkstra, I think, saw computer programming purely as an intellectual
exercise, one that did not require access to a physical computer in
order to be practised — all one had to do was to write the program,
prove that it was correct, and one's task was done. These days
computer programming has become just a pragmatic exercise, which is
one reason why now we have such a plethora of programming languages,
libraries, implementations, etc., from which we are expected to make
an informed choice. And for those of my generation (I am now 73),
this is simply an impossible task. I have no idea what "react"
is/does, why no two Unices are the same, why (in general) open braces
no longer appear vertically above the brace that closes them, etc.
The world has moved on, and I have been left behind. But that does
not prevent me from yearning for "the good old days", when /enormous/
thought went into the specification of a new programming language, and
when there was rigour where now there is chaos. But I digress (also
an artifact of old age). My point is simply that there /must/ be a
specification for something, otherwise that "something" is at best
unreliable and at worst completely useless. If I have a specification
for (say) colour \specials, and (e.g.,) xdvipdfmx (2021 release) does
not honour those specials in the same way that the 2020 release did,
then I have a definitive document which will allow me to determine
which (if either) is the correct/compliant behaviour, and which is the
incorrect/deviant. Without such a specification, then what works
today may not work tomorrow, and no-one will be able to say whether
this is evolutionary or retrograde.
[snip]
I doubt that any one implementation used in 2020 is from 1992, and
each new implementation may bring with it new difficulties.
Yes, it may. But if we have a specification (even one dated 1992), we
can definitively know and state whether each new implementation is
compliant or abberant. This must, surely, be a Good Thing [tm], must
it not ?
** Phil.
