Hints on Programming Language Design

This page contains notes on the paper "Hints on Programming Language Design" by C.A.R. Hoare. Here is a summary of the major points that jumped out at me.

Hoare is for:

• Languages that aid the programmer in design, documentation, and debugging
• Small, simple designs
• Static analysis and typing
• Safety (bounds checking, etc.)
• Fast compilation and efficient code
• Readability
• Dumpable images
• A superb comment convention!
• Mutable state (for efficiency)
• Type extensions + operator overloading
• Consolidating best of existing features when designing a new language

Hoare is against:

• Separate debug & production builds
• Implicit type conversions/coercion
• Reference types and pointers
• "Independent" compilation
• Syntactic extensions of any kind
• Including untried/unproven ideas in a new language

The following sections contain notes and quotes from the corresponding sections of the paper.

Hoare's five "catch-phrases" that summarize good language design:

1. Simplicity
2. Security
3. Fast Translation
4. Efficient object code
5. Readability

If the purpose of a programming language is to assist in the documentation of programs, the design of a superb comment convention is obviously our most important concern.³

Wow! Bold statement! He presents some good arguments in favor of newline-terminated comments (as opposed to open/close pairs like in ANSI C).

What's so great about arithmetic notation like E + F? Well, a lot! Hoare lists six "fundamental principles of structuring":

1. Transparency of meaning and purpose
2. Independence of parts
3. Recursive application
4. Narrow interfaces
5. Manifestness of structure

Hoare likes operators that can accept and return composite data structures.

Often the programmer wishes to deal with much larger data structures, for example, vectors or matrices or lists; and languages such as APL and LISP have permitted the use of expressions with these structures as operands and results. This seems to be an excellent direction of advance in programming language design, particularly for special purpose languages.

Indeed! Goes on to suggest that a compromise for efficiency is to provide operators that specifically do in-place updates. I.e. A.+B instead of A := A + B for matrices, or L1.append(L2) for lists. Hmmm, did Guido read this paper?

Hoare also likes extensible languages, but not syntactic extensions. Sorry, macros! He only wants the ability to define new types, including low-level details like their layout in memory, and then the ability to define overloaded operators on those types.

Also, Hoare is not amused by implicit type conversions.

A solution to this problem is to design a general purpose language which provides the programmer with the tools to design and implement his own representation for data and code the operations upon it. This is the main justification for the design of "extensible" languages, which so many designers have aimed at, with rather great lack of success. In order to succeed, it will be necessary to recognize the following:

1. The need for an exceptionally efficient base language in order to define the extensions.
2. The avoidance of any form of syntactic extension to the language. All that is needed is to extend the meaning of the existing operators of the language, an idea which was called "overloading" by McCarthy.
3. The complete avoidance of any form of automatic type transfer, coercion, or default convention, other than those implemented as an extension by the programmer himself.

Hoare gives an example of ugly syntax, ALGOL 60's switch statement:

switch SS = L1, L2, L3;
...
go to SS[i];

L1: Q1; go to L;
L2: Q2; go to L;
L3: Q3;
 L:

which is clearly terrible. I enjoy finding relics like this in old papers. It gives you an appreciation for how much work has gone into improving languages over the years, even little details like decent syntax for a switch statement, which we now take for granted. Speaking of a newfound appreciation for language features which we now take for granted, earlier in the section Hoare praises ALGOL 60 for innovations such as "its compound, conditional, for, and procedure statements." Useful, those! He continues:

The advantages of the use of these program structures is becoming apparent even to programmers using languages which do not provide the notations to express them.

Poor bastards.

Another interesting historical tid-bit: Hoare apparently was the inventor of the case statement, which he conceived as an improvement over ALGOL 60's switch.

case i of
  {Q1,
   Q2,
   Q3};

Hoare is not a fan of reference types or pointers:

References are like jumps, leading wildly from one part of a data structure to another. Their introduction into high level languages has been a step backward from which we may never recover.

Procedure calls should:

• produce compact code (no long prelude/postlude).
• indicate which arguments, if any, are modified.

Argues in favor of static typing and against implicit type coercion.

Language design != feature design.

When designing a feature:

• focus on one feature at a time
• ensure the new feature is an improvement and doesn't break anything
• know how to implement the feature efficiently
• write docs explaining and motivating the feature, with examples
• write example programs using the feature

When designing a language:

• should be familiar with many alternate features and have excellent judgment to choose the best among competing alternatives
• must be able to reconcile minor inconsistencies among features to present a coherent whole.
• must have a clear idea of the scope & purpose of the new language
• should have resources to write the implementation and good docs
• should have political will & resources to sell the language
• should not include untried ideas of his own! "His task is consolidation, not innovation."

A final hint: listen carefully to what language users say they want, until you have an understanding of what they really want. Then find some way of achieving the latter at a small fraction of the cost of the former. This is the test of success in language design, and of progress in programming methodology.