These are excessively thorough solutions for Reading A study questions
turned in by Derek Rayside.

-------------------------------------------------

1.  What does Jacky say is the only role for testing? Do you agree?

    "The proper role of testing is to confirm our understanding of the
    requirements and check our assumptions about the compiler,
    operating system, hardware, and other aspects of the environment
    where our program has to work."

    "When we are done, testing demonstrates to customers and other
    witnesses that the development was done correctly."

    I agree with Jacky in that testing can fruitfully be used to
    confirm understanding of requirements and to demonstrate to other
    stakeholders that the development was done correctly.  However, I
    disagree with him as to when in the development cycle this can and
    should happen:  he seems to see it at the end of the line.  I
    see value in the extreme programming idea of "test first
    programming", where test cases are developed before the program
    itself, as examples of what the program is supposed to do in
    particular cases.

    I also disagree that testing is the only technological approach to
    verifying program correctness.  I still hold out some hope for
    other static and dynamic analysis techniques.

    Jacky also does not anticipate automated test case generation,
    such as that done by Sarfraz and Darko.  This kind of automated
    test case generation, in combination with the small-scope
    hypothesis, makes testing a different beast than what Jacky
    conceives of it as.


2. How does Lampson describe a "beautiful program"? Does this sound
right to you?

    "A beautiful program is like a beautiful theorem:  It does the job
    elegantly.  It has a simple and perspicuous structure; people say,
    'Oh yes, I see that's the way to do it.'"

    Pretty much everything after the colon sounds right to me.  Here
    Lampson is echoing Aquinas (whether he does so intentionally I do
    not know).  In the commentary on the metaphysics Aquinas writes
    that the beautiful is that which posses unity, order, and harmony;
    in the Summa as that which when seen pleases.

    I take issue with the bit before the colon (which represents one
    of the grand old views of formal methods):

        - This is pedantic, but a theorem is the conclusion of an
          argument.  A program is more like a proof:  it is the
          argument.  That is probably what Lampson meant to say:
          that is one of the traditional views.

        - I don't buy the traditional view that programs are like
          proofs, and that programming is like proving theorems.  I've
          done a certain amount of both, and they just feel different
          to me.  Programs are probably closer to proofs than to
          poems, but once you get over that broad similarity I do not
          find it useful to think of programs as proofs.  One wouldn't
          use a book on how to write proofs to learn how to program;
          similarily one wouldn't use a programming book to learn how
          to write proofs (ignoring the practical issues of syntax and
          tools, of course:  the two tasks are intellectually
          different).


3. What feature of Algol 60 excited Hoare and why? For Hoare, what is
the higher goal of programming language design? Which of his comments
look dated and which have stood the test of time? Give one example of
each.

    Hoare was excited by recursion because it meant he could easily
    express his quicksort algorithm.

    For Hoare, the higher goal of programming language design is "to
    enable good ideas to be elegantly expressed".

    The first three principles that Hoare gives are still relevant:
    memory safety (what he calls "security"), brevity of object code,
    and efficiency of procedure calls.  His insistence on single pass
    compilers is out of touch with the capabilities of modern
    machines.


4. Is Hall's analogy between software and cars appropriate? Does Hall
think that construction-by-correctness can eliminate all defects?

    I think that the customer expectation part of Hall's analogy is
    reasonable, although the technical details may not be.  Too often
    software fails to perform as advertised.  It is interesting to
    note that the software being put into cars these days doesn't seem
    to be of any higher quality than most of the other mediocre
    software that surrounds us in the rest of the world.

    No, Hall does not think that construction-by-correctness can
    eliminate all defects.  He only claims that it reduces the number
    of defects introduced, and that they are often found earlier on in
    the development process.


5. It is quite possible that Fred's project was fundamentally complex
and Jane's was not. As a manager, how would you evaluate the quality
of their work?

    I would use my own judgment.  That answer is not satisfactory
    insofar as it's not terribly useful guidance for someone else.  I
    suppose one way to phrase the intuition would be to ask yourself
    the question, does this work remind me more of the equations I
    learnt in high school physics, or of tax legislation?  The person
    for whom these two things does not differ is not qualified to make
    judgments about the intellectual coherence of a software design.
    The basic equations of classical mechanics are simple, elegant,
    and unified (as far as it goes).  Tax legislation is usually a big
    ball of duct tape that accumulates over time as each legislator
    adds his own strips here and there.  It is supposed to have
    guiding principles (for example, that a given dollar of income is
    taxed only once), but one is often hard pressed to see these
    patterns in the sea of special cases, exceptions, and political
    pork.