Manifest: Tuesday, 8 February 2000

Assignments Due
Right Now	Start working in your Language Study Panel.
Wednesday, 16 Feb	Project Proposals - nothing else will be due until after the project proposals, so you should be able to make substantial progress on your projects in the next two weeks!
Monday, 21 Feb 11:59pm	Position Paper 2: An Array of Arrays

Read before Thursday's class (handed out today):

·	Turbak & Gifford, Applied Semantics of Programming Languages. Chapter 13 excerpt (p. 469-474).
		A taxonomy of types. In class, we will use latent instead of implicit, and manifest instead of explicit. Try to fit other languages you know into the circles on p. 472.

Read before next Tuesday's class (handed out today):

·	B. Liskov, A. Snyder, R. Atkinson and C. Schaffert. Abstraction Mechanisms in CLU. Comm. ACM, August 1977.
		Go through the CLU Worksheet as you read this paper.
·	Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. Chapter 4: Data Abstraction. 1986.
		Required: Sections 4.5, 4.6 and 4.9.4 only. Read the rest if you were confused by parts of the Abstraction Mechanisms in CLU paper.
·	Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. Appendix A: CLU Reference Manual. 1986.
		Not required. You don't need to read this, but use it for reference if you want to figure out details of CLU examples.

Read before Position Paper 3 (not yet handed out, will be due 28 Feb)

·	J. G. P. Barnes. An Overview of Ada. Software Practice and Experience, 1980.
		What are the differences between Ada and CLU? Which language would you rather be used to program our nuclear missiles?

You should be able to speak coherently about at least 3 complete rows and 3 complete columns of the language study table we generate in class today.

Algol 68 Minority Report

We regard the current Report on Algorithmic Language ALGOL 68 as the fruit of an effort to apply a methodology for language definition to a newly designed programming language. We regard the effort as an experiment and professional honesty compels us to state that in our considered opinion we judge the experiment to be a failure in both respects.

The failure of the description methodology is most readily demonstrated by the sheer size of the Report in which, as stated on many occasions by the authors, "every word and every symbol matters" and by the extreme difficulty of achieving correctness. The extensive new terminology and the typographical mannerisms are equally unmistakable symptoms of failure. We are aware of the tremendous amount of work that has gone into the production of the Report, but this confirms us in our opinion that adequacy is not the term that we should employ of its approach. We regard the high degree of inaccessibility of its contents as a warning that should not be ignored by dismissing the problems of "the uninitiated reader." That closer scrutiny has revealed grave deficiencies was only to be expected.

Now the language itself, which should be judges, among other things, as a language, in which to compose programs. Considered as such, a programming language implies a conception of the programmer's task. We recognize that over the last decade the processing poawer of commonly available machines has grown tremendously and that society has increased its ambition in their application in proportion to this growth. As a result the programmer of today and tomorrow, finding his task in the field of tension between available equipment and desired applications, finds himself faced with tasks of completely different and still growing scope and scale. More than ever it will be required from an adequate programming tool that it assists, by structure, the programmer in the most difficult aspects of his job, that is, in the reliable creation of sophisticated programs. In this respect we fail to see how the language proposed here is a significant step forward: on the contrary, we feel that its implicit view of the programmer's task is very much the same as, say, ten years ago. This forces upon us the conclusion that, regarded as a programming tool, the language must be regarded as obsolete.

The present minority report has been written by us because if we had not done so, we would have forsaken our professional responsibility towards the computing community. We therefore propose that this Report on the Algorithmic Language ALGOL 68 should not be published under IFIP sponsorship. If it is so published, we recommend that this "minority report" be included in the publication.

Signed by: Dijkstra, Duncan, Garwick, Hoare, Fandell, Seegmuller, Turski, Woodger.

University of Virginia CS 655: Programming Languages

cs655-staff@cs.virginia.edu