Class 03: Design Issues
Held Friday, January 29
- 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.
- Questions on Hoare?
- If you don't have any, I have some for you.
- 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
- 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.
- 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.
- 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
- 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
- For example, Java has standards for naming, commenting, and
- 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?
- 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.