From: Cliff Schmidt (cliff_at_bea.com)
Date: Wed Jan 07 2004 - 14:54:31 PST
My impressions from the Dijkstra paper can be divided into historically
interesting pieces (although most of it would fit that category to some
extent), surprising statements, and interesting technical arguments.
Historically Interesting Statements:
- Dijkstra refers to the usual type of mistake of "paying too much attention
to eliminating what was not the real bottleneck". That sure is still a
common problem today.
- Interesting to see an early reference to process deadlocking when he
describes the importance of the absence of "circular waits" AKA "the Deadly
Embrace".
- It was especially historically interesting to read him explain the concept
of processes that can exist independently of the number of processors. I
also enjoyed the discussion of how undefined speed ratios was not a problem
when using explicit mutual synchronization statements.
Surprising Statements:
- He seems to view debugging as something that should be avoided since it is
so difficult. The funny part was that he claimed that it is possible to
design a system "in such a way that its logical soundness can be proved a
priori and its implementation can admit exhaustive testing." Also, "the
resulting system is guaranteed to be flawless" and "we shall have proved
the correctness of the system with a rigor and explicitness that is unusual
for the great majority of mathematical proofs". That last statement could
be considered true today since today's rigor would be so incredibly
insufficient for any mathematical proof. However, just as I was wondering
whether Dijkstra really believed that the most complex systems could be
exhaustively proved, I noted his statement in the concluding section, "one
cannot subject it to all possible cases: for a computer this would imply
that one feeds it with all possible programs! Therefore one must test it
with a set of relevant test cases." I do appreciate his point that the
designer must be held responsible to architect a system that can be easily,
clearly, and incrementally tested.
Interesting Technical Arguments:
- I really liked the way he explains the system hierarchy from level 0 to
level 5. He makes clear the importance of each abstraction and its
relative position to the others, also why it was important for the "message
interpreter" to separate the independent input and output peripherals.
Earlier in the paper he also points out how his distinction between memory
units and information units frees him of the drum allocation problem, since
there is no longer any reason for a program to occupy consecutive drum
pages.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 14:54:33 PST