Held: Monday, January 30, 2006
Summary:
Today we consider some basic design issues for programming languages and
expand upon some particular details from Hoare and Wirth.
Related Pages:
Assignments
- Read Paul Graham's
Revenge of the Nerds
(due Wed.).
- Read John McCarthy's
History of LISP
(sorry, only in PDF) (due Wed.).
- Read John McCarthy's
Recursive Functions of Symbolic Expressions
and Their Computation by Machine, Part I
(due Fri.).
- You may find it useful to refer to Paul Graham's
The Roots of Lisp
to understand the second McCarthy paper (due Fri.).
Notes:
- Please strive to submit your comments by midnight.
- Please cut and paste reading comments into your email messages. I dislikeattachments.
Overview:
- Notes from the readings.
- Choosing a language.
- Key design criteria.
Some questions from the readings ...
- What do the authors have in mind as the best type of programming language?
- Have there been any major language design revolutions since the 1970's?
- Do you agree with the authors' emphasis on natural efficiency of compiled
code?
- 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
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 support exception handling? Does it permit aliasing?
;
Check with Bobby