P ROGRAMMING L ANGUAGES
L ECTURE 02:
G OOD P ROGRAMMING
L ANGUAGE D ESIGN
Dr. Shahriar Bijani
Sep 2014

M AIN S LIDE R EFERENCES

Programming Language Design and Implementation
(4th ed), T. Pratt and M. Zelkowitz, Prentice Hall,
2001: chapter 3.

CS 152: Programming Language Paradigms
R. Mak, SJSU Dept. of Computer Science, Spring
2014.

PZ02A, T. Pratt and M. Zelkowitz, Programming
Language design and Implementation -4th Edition,
Prentice Hall, 2000.
2

P OPULARITY OF P ROGRAMMING L ANGUAGES
3

P OPULARITY OF P ROGRAMMING L ANGUAGES
4

G OOD P ROGRAMMING L ANGUAGE D ESIGN

What is good programming language design?


What criteria should be used to judge a language?
How should success or failure of a language be defined?

A language design is successful if it satisfies any or all of these criteria:



It achieves the goals of its designers.

Therefore, it must have a clear goal.
It attains widespread use in an application area.
It serves as a model for other languages that are successful.
_
5

G OOD P ROGRAMMING L ANGUAGE D ESIGN

When designing a new language, choose a clear overall goal .

Keep the goal in mind throughout the design process.

This is especially important for special purpose languages

Build the abstractions for the target application area into the language design.

Example: SQL for relational databases
_
6

H ISTORICAL O VERVIEW

In the early days, machines were extremely slow and memory was scarce.

Program speed and memory usage were prime concerns.

Efficiency of execution was a primary design criterion.

Early FORTRAN code mapped closely to machine code, minimizing the amount of translation required by the compiler

Writability of a language enables a programmer to use it to express computation clearly, correctly, concisely, and quickly.


Writability of FORTRAN was less important then efficiency.
Readability was even less of a concern.
7

H ISTORICAL O VERVIEW (2)

Algol 60 was designed to express algorithms in a logically clear and concise way.

The language imposed structure on its programs.



 block structure structured control statements structured array type
It also incorporated recursion.

COBOL attempted to improve readability of programs by trying to make them look like ordinary English.

However, this made them long and verbose.
_
8

H ISTORICAL O VERVIEW (3)

In the 1970s and early 1980s, the emphasis was on simplicity and abstraction , along with reliability .


Mathematical definitions for language constructs.
Mechanisms to allow a translator to partially prove the correctness of a program before translation.


This led to strong data typing .
Examples: Pascal, Modula 2, C, Ada

In the 1980s and 1990s, the emphasis was on logical or mathematical precision .


This led to a renewed interest in functional languages.
Examples: Lisp, Scheme, ML, Haskell
_
9

H ISTORICAL O VERVIEW (3)

The most influential design criteria of the last 25 years
...

The object-oriented approach to abstraction.

The use of libraries and other object-oriented techniques increased the reusability of existing code.

In addition to the early goals of efficiency, nearly every design decision still considers

 readability abstraction
 complexity control
_
10

T ARGET C ODE E FFICIENCY

Strong data typing


Enforced at compile time.
No need at run time to check data types before executing operations.

Example: FORTRAN IV

All data declarations and subroutine calls had to be known at compile time.

Memory space is allocated once at the beginning of program execution.
_
11

P ROGRAMMER E FFICIENCY

Program reliability is an programmer efficiency issue.

Unreliable programs require programmer time to diagnose and correct.

Programmer efficiency is also impacted by the ease with which errors can be found and corrected .

Since roughly 90% of time is spent on debugging and maintaining programs, maintainability may be the most important index of programming language efficiency.
_ 12

R EGULARITY

Regularity refers to how well the features of a language are integrated.

Greater regularity implies:


Fewer restrictions on the use of particular constructs.
Fewer strange interactions between constructs.

Fewer surprises in general in the way the language features behave.

Languages that satisfy the criterion of regularity are said to adhere to the Principle of Least
Astonishment .
_
13

R EGULARITY , CONT ’ D

Regularity involves three concepts:


Generality
Orthogonal design

Uniformity

Otherwise classify a feature or construct as irregular .
_
14

R EGULARITY , CONT ’ D

Generality

Avoid special cases in the availability or use of constructs.

Combine closely related constructs into a single more general one.

Orthogonal design


Combine constructs in any meaningful way.
No unexpected restrictions or behaviors.

Uniformity


Similar things look similar and have similar meanings.
Different things look different.
_
15

G ENERALITY

Avoid special cases wherever possible.

Example: Pascal procedures and functions


You can nest procedures and functions.
You can pass procedures and functions as parameters to other procedures and functions.

However, you cannot assign procedures and functions to variables or store them in data structures.

Example: Pascal constants

You cannot compute a constant value with an expression.

Example: C operators

You cannot use == to compare two structures.
16

O RTHOGONALITY

Constructs do not behave differently in different contexts.

Nonorthogonal : context-dependent restrictions.

Lack of generality: restrictions regardless of context.

Example: Function return types


Pascal: Only scalar and pointer types.
C and C++: All data types except array types.

Ada and Python: All data types.
_
17

O RTHOGONALITY , CONT ’ D

Example: Variable declarations


C: Declare local variables only at a block beginning.
C++ and Java: Declare local variables anywhere in a block prior to their use.

Example: Java primitive and reference types

Primitive types use value semantics.


Copy values during assignments.
Reference (object) types use reference semantics.

An assignment creates two references to the same object.

Algol 68: Orthogonality was a major design goal.

Best example of a language where you can combine constructs in all meaningful ways.
18

U NIFORMITY

The appearance and behavior of language constructs are consistent.

Example: C++ semicolon


Required after a class definition.
Forbidden after a function definition.

Example: Pascal function return

Return a function value by assigning the value to the function name.


Easily confused with a standard assignment statement.
Other languages use a return statement.
_ 19

O THER DESIGN PRINCIPLES

Simplicity: make things as simple as possible, but not simpler. (Pascal, C)

Expressiveness: make it possible to express conceptual abstractions directly and simply. (Scheme)

Extensibility: allow the programmer to extend the language in various ways.
(Scheme, C++)

Security: programs cannot do unexpected damage. (Java)
20

O THER DESIGN PRINCIPLES ( CONT .)

Preciseness: having a definition that can answer programmers and implementors questions. (Most languages today, but only one has a mathematical definition: ML)

Machine-independence: should run the same on any machine. (Java)

Consistent with accepted notations. (Most languages today, but not Smalltalk & Perl)

Restrictability: a programmer can program effectively in a subset of the full language.
21

C++ CASE STUDY

Thanks to Bjarne Stroustrup, C++ is not only a great success story, but also the best-documented language development effort in history:

1997: The C++ Programming Language, 3rd Edition
(Addison-Wesley).


1994: The Design and Evolution of C++ (Addison-
Wesley).
1993: A History of C++ 1979-1991, SIGPLAN Notices
28(3).
22

M AJOR C++ DESIGN GOALS

OO features: class, inheritance




Strong type checking for better compile-time debugging
Efficient execution
Portable
Easy to implement

Good interfaces with other tools
23

S UPPLEMENTAL C++ DESIGN GOALS

C compatibility (but not an absolute goal)

Incremental development based on experience.

No runtime penalty for unused features.

Multiparadigm

Stronger type checking than C

Learnable in stages

Compatibility with other languages and systems
24

C++ DESIGN ERRORS

Too big?


C++ programs can be hard to understand and debug
Not easy to implement

Defended by Stroustrup: multiparadigm features are worthwhile

No standard library until late (and even then lacking major features)

Stroustrup agrees this has been a major problem
25