Class 03: Design Issues

Held Friday, January 29

Summary

• Basic criteria for evaluating languages
• Some additional criteria
• Reading: Louden, Chapter 3
• Reading: C.A.R. Hoare: ``Hints on Programming Language Design''
• Assignment one (language design issues) distributed. Due Friday, February 5, 1999.

Contents

Notes

• Questions on Hoare?
  • If you don't have any, I have some for you.

History, Revisited

• While we only got a little way through the history of programming languages, I'm going to stop at this point. We'll return to some historical issues when we talk about particular paradigms.
• I'll note that each of the four ``primary'' language paradigms were developed fairly early:
  • Imperative programming: Fortran, 1958; the standard for algorithms for thousands of years.
  • Functional programming: LISP, 1960; based on the lambda calculus from the 1920's.
  • Object-oriented programming: Simula-67, 1967; not clear how it's been used outside of programming languages and engineering type situations (although I welcome suggestions)
  • Logic programming: Prolog, 1972; logic as ``the formalization of what mathematicians do'' early 1900's.

Some Criteria for Evaluating Languages

• Suppose you needed to decide whether a language is appropriate for some task. What are some of the issues that you might consider? Many people look at four basic criteria.
• Readability: How easy is it to read (and comprehend) a program (or portion thereof) written in the language?
• Writability: How easy is it to write programs (or particular kinds of programs) in the language?
• Reliability: How easy is it to write robust programs? Does the language help prevent errors.
• Cost: How expensive is it to develop, use, and maintain programs written in the language.

Additional Criteria

• There are also a number of other, "more primitive" criteria that help contribute to the four basics.

• Simplicity. A language should not have too many features nor too many ways to express the same concept.
  • However, too much simplicity can lead to too much complication if the language has no direct support for something the programmer wants to do.
• Orthogonality and Uniformity. Primitive operations can be combined freely to provide more powerful operations. The same operation can always be used in the same when. Also a lack of "special cases".
• It should be easy to work with abstractions of subproblems and data, rather than always dealing with underlying representation or implementation.
  • Rich Control Structures.
    • And perhaps even support for developing new ones.
  • Support for defining and using Data Structures.
    • Some would also include overloading to support common syntax for operations on those data structures.
• A useful Typing System.
  • And other instances of compile-time error detection.
• A clear, understandable, and reasonable Syntax.
  • The legendary "NASA Fortran DO typo" is an example of bad syntax, as is the =- operator in the original C.
  • Some theorists say ``If it's difficult to write a program to parse it, it's probably difficult for a programmer to get it right.''
• A language with standards for writing programs often has greater readability.
  • For example, Java has standards for naming, commenting, and capitalization.
  • Standards for libraries also enhance maintainability.

• The list can also consider fairly detailed issues. For example, does the language permit exception handling? Does it permit aliasing?

History

• Created Tuesday, January 19, 1999 as a blank outline.
• Filled in the details on Wednesday, January 27, 1999 (based, primarily, on last year's class).
• Added additional notes on history on Friday, January 29, 1999. Also modified the additional criteria somewhat.