Good Language Design

advertisement
PROGRAMMING LANGUAGES
LECTURE 02:
GOOD PROGRAMMING
LANGUAGE DESIGN
Dr. Shahriar Bijani
Sep 2014
MAIN SLIDE REFERENCES



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
POPULARITY OF PROGRAMMING LANGUAGES
3
POPULARITY OF PROGRAMMING LANGUAGES
4
GOOD PROGRAMMING LANGUAGE DESIGN

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
GOOD PROGRAMMING LANGUAGE DESIGN

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
HISTORICAL OVERVIEW

In the early days, machines were extremely slow
and memory was scarce.


Efficiency of execution was a primary design
criterion.


Program speed and memory usage were prime concerns.
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
HISTORICAL OVERVIEW (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
HISTORICAL OVERVIEW (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
HISTORICAL OVERVIEW (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
TARGET CODE EFFICIENCY

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
PROGRAMMER EFFICIENCY

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
REGULARITY


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
REGULARITY, CONT’D

Regularity involves three concepts:
Generality
 Orthogonal design
 Uniformity


Otherwise classify a feature or construct as irregular.
_
14
REGULARITY, 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
GENERALITY

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
ORTHOGONALITY

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
ORTHOGONALITY, 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.


Reference (object) types use reference semantics.


Copy values during assignments.
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
UNIFORMITY


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
OTHER 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
OTHER 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++ (AddisonWesley).
 1993: A History of C++ 1979-1991, SIGPLAN Notices
28(3).

22
MAJOR 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
SUPPLEMENTAL 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
Download
Related flashcards

Computer programming

24 cards

Programming constructs

28 cards

Create Flashcards