Transcript Good Language Design
P ROGRAMMING L ANGUAGES
L ECTURE
G OOD P
02:
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 criterion.
was a primary design 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 issue.
is an programmer efficiency 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, language efficiency.
_ maintainability may be the most important index of programming
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 features behave.
in general in the way the language 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