Programming Language
Design
Chapter 1
CS 350 Programming
Language Design
Indiana University – Purdue
University Fort Wayne
1
Chapter 1: Preliminaries
Reasons for Studying Programming
Languages
Programming Domains
Language Evaluation Criteria
Influences on Language Design
Language Categories
Language Design Trade-Offs
Implementation Methods
Programming Environments
2
Reasons for Studying
Programming Languages
The expressive power of the language
we use to communicate influences the
depth at which we can think
It is difficult to conceptualize structures
you cannot describe
Consider implementing a complex
application in assembly language
without knowledge of subprograms or object-
oriented programming?
with that knowledge?
3
Reasons for Studying
Programming Languages
Ability to choose the best language for
the problem
Popular languages used today are far from
ideal
Is a cheap compiler a good reason for
choosing a language?
Is programmer familiarity with a related
language a good reason for choosing a
language?
Foundation for learning new languages
4
Reasons for Studying
Programming Languages
Understanding of runtime and
implementation issues
Relative efficiency of alternative
constructs
Common bugs
Proper use of a language
Overall advancement of computing
5
Programming Domains
Scientific applications
Large number of floating point
computations
Examples: Mathematica and Maple
Business applications
Produce reports
Use decimal numbers and characters
COBOL
6
Programming Domains
Artificial intelligence
Symbols rather than numbers are typically
manipulated
First AI language was LISP – McCarthy
Prolog – Clocksin and Mellish
Systems programming
Need for efficiency because of continuous
use
Low-level features for interfaces to external
devices
C
7
Programming Domains
Web software
Markup languages
Such as XHTML
Scripting languages
A list of commands is placed in a file or in XHTML
document for execution
Perl, JavaScript, PHP
Special-purpose languages
RPG – business reports
APT – programmable machine tools
GPSS – simulation
8
Language Evaluation
Criteria
Readability
Writability
Reliability
Cost
Other
9
Language Evaluation
Criteria
Readability
Very important
Maintenance can be 70 – 90% of system
lifecycle cost
Overall simplicity
Too many features are bad
Multiplicity of features is bad
Are you confused by Java I/O choices?
10
Language Evaluation
Criteria
Readability
Orthogonality
A relatively small set of primitive constructs that can be
combined in a relatively small number of ways
Consistent set of rules for combining constructs (simplicity)
• Every possible combination is legal
Makes the language easy to learn and read
Meaning is context independent
VAX assembly language and Ada are good examples
Lack of orthogonality leads to exceptions to rules
C is littered with special cases
• E.g. - structs can be returned from functions but arrays cannot
11
Language Evaluation
Criteria
Readability
Useful control statements
Ability to define data types and structures
Syntax considerations
Provision for descriptive identifiers
• BASIC once allowed only identifiers to consist of one
character with an optional digit
Meaningful reserved words
Meaning should flow from appearance
12
Language Evaluation
Criteria
Writability
Most readability factors also apply to writability
Simplicity and orthogonality
Control statements, data types and structures
Support for abstraction
Data abstraction
Process abstraction
Expressivity
It is easy to express program ideas in the language
APL is a good example
13
Language Evaluation
Criteria
Reliability
Type checking
Famous failure of space shuttle experiment due to int
/ float mix-up in parameter passing
Exception handling
Ability to intercept run-time errors
Aliasing
Ability to use different names to reference the same
memory
A dangerous feature
Readability and writability both influence
reliability
14
Language Evaluation
Criteria
Cost
Training programmers to use language
Writing programs in a particular problem domain
Compiling programs
Executing programs
Language implementation system (free?)
Reliability
Maintaining programs
Others: portability, generality, well-
definedness
15
Von Neumann computer
architecture
16
Influences on Language
Design
Architecture
We use imperative languages, at least in part,
because we use von Neumann machines
Data and programs stored in same memory
Memory is separate from CPU
Instructions and data are piped from memory to CPU
Basis for imperative languages
• Variables model memory cells
• Assignment statements model piping
• Iteration is the most efficient way to implement repetition
17
Influences on Language
Design
Programming methodologies
1950s and early 1960s
Simple applications
Overriding concern about machine efficiency
Late 1960s
“People efficiency” became important
Readability
Better control structures
Structured programming
Top-down design and step-wise refinement
18
Influences on Language
Design
Programming methodologies
Late 1970s
Process-oriented techniques yielded to data-
oriented techniques
Data abstraction
Middle 1980s to present
Object-oriented programming
• Encapsulation with data abstraction
• Inheritance
• Dynamic method binding
• Smalltalk and Java
Concurrent programming and parallelism
• Creating and controlling concurrent program units
19
Language Categories
Imperative
Central features
Variables
Assignment statements
Iteration
Algorithm specified in detail with a specific
order of execution for statements
C, Pascal, Visual [Link]
Functional
Main means of making computations is by
applying functions to given parameters
No variables
No looping
LISP, Scheme
20
Language Categories
Logic
Rule-based
Rules are specified in no special order
Language system chooses execution order
that produces the desired result
Prolog
Object-oriented
Encapsulate data objects with processing
Inheritance and dynamic type binding
Grew out of imperative languages
Smalltalk, C++, Java
21
Language Design Trade-Offs
Designing a programming language involves
an number of compromises and trade-offs
Reliability vs. cost of execution
Range checking for array references?
Readability vs. writability
The APL language traded readability for writability
Writability vs. reliability
Pascal variant records are flexible but not safe
C++ pointers are flexible but not safe
22
Layered View of
Computer
23
Implementation Methods
Compilation
Translates a high-level
program to machine
code
Slow translation
Fast execution
Separate compilation
units must be
combined by a linker
into an executable
image
(.exe file)
24
Implementation Methods
Pure interpretation
No translation before
execution
Slow execution
Loop statements are
repeatedly translated
Becoming rare except for
web scripting languages
JavaScript
PHP
25
Implementation
Methods
Hybrid implementation
systems
Translates a high-level
language to intermediate
code, which is interpreted
Each statement is translated
only once in contrast to pure
interpretation
Medium execution speed
Smalltalk and Java
Intermediate code is called
bytecode
The Java interpreter is the JVM
JIT technology now widely
used with Java and .NET
26
Programming Environments
The collection of tools used in
software development
File system, text editor, compiler, linker
Eclipse
An integrated development environment
for Java and other languages
Microsoft Visual [Link]
A large, complex visual environment
Used to program in C#, Visual
[Link], Jscript, J#, and C++
27