University of Virginia, Department of Computer Science
CS655: Programming Languages
Spring 2000

Reading Assignments

Out 20 January 2000:

· Dijkstra, How do we tell truths that might hurt?, 1975

Boldness in language critiques

· Dijkstra, A parable, 1973

What does this have to do with programming language design?

· Fred Brooks, Language Design as Design, HOPL-II keynote address, 1993 (no electronic version available)

Principles of good design - when you write your Position Paper, think about violations of these principles.

· Kernighan, Why Pascal Is Not My Favorite Programming Language, 1981
This is optional. Read it if you need inspiration (but not a model) for your Position Paper. Your paper should do a better job than Kernighan did of focusing on fundamental language design flaws.

· Turbak & Gifford, Applied Semantics of Programming Languages. Chapters 1 and 3.

Introduction, Operational Semantics.

Out 27 January 2000:

· Wenger, Programming Languages - The First 25 Years. IEEE Trans. on Computers, Dec 1976.

This paper was written in 1976. When you read it, consider how many of the developments the Java marketers have been trumpeting were already known. Come to class prepared to discuss how well Wenger's categories hold today, in terms of the languages you know.

· Bernad A. Galler, The FORTRAN Language; David Gries, Algol 60 Language Summary

One page language summaries from the ACM History of Programming Languages Conference, 1978. The FORTRAN summary should give you some idea of the state-of-the-art before Algol.

· P. Nauer, et. al., Report on the Algorithmic Language Algol 60. Comm. of the ACM, 1963.

This was a landmark in both language design and description. It was the first document to describe a language syntax using a systematic notation (subsequently known as "Backus-Naur Form"). Algol60 had many interesting features, some of which became adopted in nearly all programming languages we use today, and others which disappeared. As you read this paper, think about which features survived and try to understand why others didn't.

· D. E. Knuth, The Remaining Troublespots in Algol 60. Comm. of the ACM, 1967.

Four years after the original report, people are still arguing over ambiguities in the language definition. Was this because of flaws in the design, or flaws in the description?

Out 1 February 2000:

Note: You don't need to read all of these papers, but should select either the Algol68 paper and any other paper of your choosing (where the two Pascal papers count as one), or all the other four papers:

       (Algol68 + (Bliss | both Pascal Papers | C)) 
     | (Bliss + both Pascal Papers + C)

These papers describe four languages of the late sixties - early seventies. Most programming language researchers consider C the worst of the four, but it is undeniably the most successful. As you read these papers, try to figure out what it was the other languages did wrong and C did right, to lead to the other languages failure (except arguably Pascal), and C's success.

· A. S. Tanenbaum. A Tutorial on Algol 68, Computing Surveys, 1976.

Algol 68 is a very interesting and influential language, but was never widely used. It illustrates where a deisgn principle (in this case orthogonality) is followed to such an extent that practical considerations are ignored.

· W. A. Wulf, D. B. Russell, and A. N. Habermann. BLISS: A Language for Systems Programming. Communications of the ACM, December 1971.

Pay particular attention to the section on Data Structures.

· N. Wirth. An Assessment of the Programming Language Pascal, IEEE Transactions on Software Engineering, June 1975.

· J. Welsh, W. Sneeringer and C. A. R. Hoare. Ambiguities and Insecurities in Pascal, Software Practice and Experience, 1977.

Two short papers evaluating Pascal. Read these thinking about how well Pascal accomplished its design goals.

· D. M. Ritchie, S. C. Johnson, M. E. Lesk and B. W. Kernighan. The C Programming Language. Bell System Technical Journal, July-August 1978.

They write, Several hundred programmers within Bell Laboratories and many outside use C as their primary programming language. How come C became so succesful?

Out 8 February 2000:

· 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.

· 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.

· 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?

Out 15 Feb:

· Bjarne Stroustrup. What is "Object-Oriented Programming"?. Proceedings of the First European Software Festival, 1991 revised version.

The object of reading this paper is for you to think objectively about whether or not you object to Stroustrup's possibly objectionable definition of object-oriented programming. Read his section 3 with a critical eye - how many of his complaints about data abstraction facilities are solved by languages with good support for data abstraction (such as CLU)? Does his definition of an abstract type (he prefers "user-defined type") bely a prejudice or a lack of understanding? His description of an exception mechanism that resembles the ones found in Clu (sic) either is incorrect or assumes a very loose definition of resembles (we'll return to this later, after reading a paper on CLU's exception mechanisms).
You should be able to find at least two bugs or serious deficiencies in his example programs. (Despite all these flaws, its a good paper summarizing the language features that enable object-oriented programming.)

· Daniel Ingalls. Design Principles Behind Smalltalk. BYTE Magazine, August 1981.

This paper presents a starkly different view of what object-oriented programming is all about from the Stroustrup paper. Twenty years later, typical programmers are still using languages far further from natural thought processes than Smalltalk-80. How do you think the Smalltalk designers think about their Natural Selection property today?

· Raymie Stata and Martin Abadi. A Type System for Java Bytecode Subroutines. POPL '98.

Make sure to read and understand complete Sections 1-4 (you'll need to understand this well to do Problem Set 3, will be handed out Thursday). You should attempt to read the rest of the paper, but don't worry if you don't understand everything in Sections 5-7. This is a recent paper in the premier theoretical programming languages conference - if you succeed in understanding it, you should consider this a major accomplishment, pat yourself on the back, and enjoy the beverage of your choice. (And then get back to working on your project.)

· Barbara Liskov and Jeannette Wing. Behavioral Subtyping Using Invariants and Constraints. CMU-CS-99-156 (based on November 1994 ACM TOPLAS paper.)

A challenging, but worthwhile paper. As you read it, attempt to relate their rules for subtyping to the programming problem they are trying to solve: making programs written without knowledge of all possible subtypes work as expected with new subtypes.

Out 17 Feb:

· Bertrand Meyer. Eiffel: An overview of the language and method From ISE Eiffel: The Environment, 1995.

· Bertrand Meyer. Static typing and other mysteries of life. Keynote lecture at OOPSLA '95.

Most programming language experts believe Eiffel's type system is seriously flawed. Can you figure out why?

· Clemens Szypersky, Stephen Omohundro, Stephan Murer. Engineering a Programming Language: The Type and Class System of Sather . ICSI Techreport TR-93-064.

Sather was designed to fix some of the flaws in Eiffel. Identify at least one substantial improvement in Sather and send mail to cs655-staff@cs.virginia.edu describing it. If you can't, send mail with three questions relating to the assigned readings. This mail should be received before 11am on Thursday 24 Feb.

· Stephan Murer, Stephen Omohundro, David Stoutamire and Clemens Szyperski. Iteration Abstraction in Sather. Transactions on Programming Languages and Systems, Jan 1996.

Optional, but interesting. Are Sather's iterators more like Algol's call-by-name or CLU's iterators?

· John Viega, Paul Reynolds and Reimer Behrends. Automated Delegation is a Viable Alternative to Multiple Inheritance in Class Based Languages. 1999.

Send me one good quesion or comment about this paper before 11am 29 Feb. John Viega will give a guest lecture based on this work in class on 29 Feb.

Out 29 Feb:

· Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. Chapter 11: A Quick Look at Program Verification. 1986.

An introduction to axiomatic semantics and program verification.

Read before Tuesday 7 Mar:

· George Necula and Peter Lee. Safe Kernel Extensions Without Run-Time Checking. Second Symposium on Operating Systems Design and Implementation (OSDI '96), October, 1996.

You may skip section 3.1. This paper describes proof-carrying code, a practical (?) application of axiomatic semantics. Before 11am Tuesday 7 Mar, send me a three-line email message on whether on not you think proof-carrying code is useful.

Court's Exhibit 1:

· Bjarne Stroustrup. A History of C++: 1979-1991. Paper and talk transcript from History of Programming Languages II conference, 1993.

Jurors: Required reading before trial begins (28 March).
Attorneys: Each team of attorneys should read the whole thing, but you can divide it into parts as you see fit.
Witnesses: Read as much or little as you feel is necessary to prepare you for trial. (Most should probably be reading papers relevant to your witness instead.)
Defendant: Read before planning your deposition questions.

University of Virginia
CS 655: Programming Languages

cs655-staff@cs.virginia.edu
Last modified: Mon Feb 26 12:48:11 2001

·	Dijkstra, How do we tell truths that might hurt?, 1975
		Boldness in language critiques
·	Dijkstra, A parable, 1973
		What does this have to do with programming language design?
·	Fred Brooks, Language Design as Design, HOPL-II keynote address, 1993 (no electronic version available)
		Principles of good design - when you write your Position Paper, think about violations of these principles.
·	Kernighan, Why Pascal Is Not My Favorite Programming Language, 1981
		This is optional. Read it if you need inspiration (but not a model) for your Position Paper. Your paper should do a better job than Kernighan did of focusing on fundamental language design flaws.
·	Turbak & Gifford, Applied Semantics of Programming Languages. Chapters 1 and 3.
		Introduction, Operational Semantics.

·	Wenger, Programming Languages - The First 25 Years. IEEE Trans. on Computers, Dec 1976.
		This paper was written in 1976. When you read it, consider how many of the developments the Java marketers have been trumpeting were already known. Come to class prepared to discuss how well Wenger's categories hold today, in terms of the languages you know.
·	Bernad A. Galler, The FORTRAN Language; David Gries, Algol 60 Language Summary
		One page language summaries from the ACM History of Programming Languages Conference, 1978. The FORTRAN summary should give you some idea of the state-of-the-art before Algol.
·	P. Nauer, et. al., Report on the Algorithmic Language Algol 60. Comm. of the ACM, 1963.
		This was a landmark in both language design and description. It was the first document to describe a language syntax using a systematic notation (subsequently known as "Backus-Naur Form"). Algol60 had many interesting features, some of which became adopted in nearly all programming languages we use today, and others which disappeared. As you read this paper, think about which features survived and try to understand why others didn't.
·	D. E. Knuth, The Remaining Troublespots in Algol 60. Comm. of the ACM, 1967.
		Four years after the original report, people are still arguing over ambiguities in the language definition. Was this because of flaws in the design, or flaws in the description?

·	A. S. Tanenbaum. A Tutorial on Algol 68, Computing Surveys, 1976.
		Algol 68 is a very interesting and influential language, but was never widely used. It illustrates where a deisgn principle (in this case orthogonality) is followed to such an extent that practical considerations are ignored.
·	W. A. Wulf, D. B. Russell, and A. N. Habermann. BLISS: A Language for Systems Programming. Communications of the ACM, December 1971.
		Pay particular attention to the section on Data Structures.
·	N. Wirth. An Assessment of the Programming Language Pascal, IEEE Transactions on Software Engineering, June 1975.
·	J. Welsh, W. Sneeringer and C. A. R. Hoare. Ambiguities and Insecurities in Pascal, Software Practice and Experience, 1977.
		Two short papers evaluating Pascal. Read these thinking about how well Pascal accomplished its design goals.
·	D. M. Ritchie, S. C. Johnson, M. E. Lesk and B. W. Kernighan. The C Programming Language. Bell System Technical Journal, July-August 1978.
		They write, Several hundred programmers within Bell Laboratories and many outside use C as their primary programming language. How come C became so succesful?

·	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.
·	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.
·	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?

·	Bjarne Stroustrup. What is "Object-Oriented Programming"?. Proceedings of the First European Software Festival, 1991 revised version.
		The object of reading this paper is for you to think objectively about whether or not you object to Stroustrup's possibly objectionable definition of object-oriented programming. Read his section 3 with a critical eye - how many of his complaints about data abstraction facilities are solved by languages with good support for data abstraction (such as CLU)? Does his definition of an abstract type (he prefers "user-defined type") bely a prejudice or a lack of understanding? His description of an exception mechanism that resembles the ones found in Clu (sic) either is incorrect or assumes a very loose definition of resembles (we'll return to this later, after reading a paper on CLU's exception mechanisms). You should be able to find at least two bugs or serious deficiencies in his example programs. (Despite all these flaws, its a good paper summarizing the language features that enable object-oriented programming.)
·	Daniel Ingalls. Design Principles Behind Smalltalk. BYTE Magazine, August 1981.
		This paper presents a starkly different view of what object-oriented programming is all about from the Stroustrup paper. Twenty years later, typical programmers are still using languages far further from natural thought processes than Smalltalk-80. How do you think the Smalltalk designers think about their Natural Selection property today?
·	Raymie Stata and Martin Abadi. A Type System for Java Bytecode Subroutines. POPL '98.
		Make sure to read and understand complete Sections 1-4 (you'll need to understand this well to do Problem Set 3, will be handed out Thursday). You should attempt to read the rest of the paper, but don't worry if you don't understand everything in Sections 5-7. This is a recent paper in the premier theoretical programming languages conference - if you succeed in understanding it, you should consider this a major accomplishment, pat yourself on the back, and enjoy the beverage of your choice. (And then get back to working on your project.)
·	Barbara Liskov and Jeannette Wing. Behavioral Subtyping Using Invariants and Constraints. CMU-CS-99-156 (based on November 1994 ACM TOPLAS paper.)
		A challenging, but worthwhile paper. As you read it, attempt to relate their rules for subtyping to the programming problem they are trying to solve: making programs written without knowledge of all possible subtypes work as expected with new subtypes.

·	Bertrand Meyer. Eiffel: An overview of the language and method From ISE Eiffel: The Environment, 1995.
·	Bertrand Meyer. Static typing and other mysteries of life. Keynote lecture at OOPSLA '95.
		Most programming language experts believe Eiffel's type system is seriously flawed. Can you figure out why?
·	Clemens Szypersky, Stephen Omohundro, Stephan Murer. Engineering a Programming Language: The Type and Class System of Sather . ICSI Techreport TR-93-064.
		Sather was designed to fix some of the flaws in Eiffel. Identify at least one substantial improvement in Sather and send mail to cs655-staff@cs.virginia.edu describing it. If you can't, send mail with three questions relating to the assigned readings. This mail should be received before 11am on Thursday 24 Feb.
·	Stephan Murer, Stephen Omohundro, David Stoutamire and Clemens Szyperski. Iteration Abstraction in Sather. Transactions on Programming Languages and Systems, Jan 1996.
		Optional, but interesting. Are Sather's iterators more like Algol's call-by-name or CLU's iterators?
·	John Viega, Paul Reynolds and Reimer Behrends. Automated Delegation is a Viable Alternative to Multiple Inheritance in Class Based Languages. 1999.
		Send me one good quesion or comment about this paper before 11am 29 Feb. John Viega will give a guest lecture based on this work in class on 29 Feb.

·	Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. Chapter 11: A Quick Look at Program Verification. 1986.
		An introduction to axiomatic semantics and program verification.

·	George Necula and Peter Lee. Safe Kernel Extensions Without Run-Time Checking. Second Symposium on Operating Systems Design and Implementation (OSDI '96), October, 1996.
		You may skip section 3.1. This paper describes proof-carrying code, a practical (?) application of axiomatic semantics. Before 11am Tuesday 7 Mar, send me a three-line email message on whether on not you think proof-carrying code is useful.

·	Bjarne Stroustrup. A History of C++: 1979-1991. Paper and talk transcript from History of Programming Languages II conference, 1993.
		Jurors: Required reading before trial begins (28 March). Attorneys: Each team of attorneys should read the whole thing, but you can divide it into parts as you see fit. Witnesses: Read as much or little as you feel is necessary to prepare you for trial. (Most should probably be reading papers relevant to your witness instead.) Defendant: Read before planning your deposition questions.