Transcript Chapter 1

Programming Languages
DIT 0202
Introduction to programming &
Algorithms
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-1
Programming Languages
professional behavior
• This is a “Junior” level class – you are nearing entry
to the job marketplace
– Please do not ask me to debug your programs!
• Programs must compile and run in the language
version available in the lab.
– If you are using some other version, recompile and retest
in the lab before submitting the lab.
– Please do not expect me or a grader to convert your code
from one implementation to another!
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-2
Chapter 1
Preliminaries
eighth
x
^
ISBN 0-321-19362-8
Programming Languages
This course:
...is a breadth-wise study of programming language
concepts
specific languages are used as representative of certain
key ideas in programming language design
...is NOT an in-depth study of specific
programming languages
somewhat like a roller coaster ride… not a journey to the
center of the earth
We will examine the fundamental structural
issues that lead programming languages to be
what they are
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-4
Chapter 1 Topics
•
•
•
•
•
•
•
•
Motivation
Programming Domains
Language Evaluation Criteria
Influences on Language Design
Language Categories
Language Design Trade-Offs
Implementation Methods
Programming Environments
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-5
Programming Languages
What is a programming Language?
• Ask 8 different Computer Scientists, get 8
different answers!
–
–
–
–
–
–
–
–
formal notation for computations
tool for writing programs
means of communicating between programmers
vehicle for expressing high-level designs
notation for algorithms
way of expressing relationships between concepts
tool for experimenting with solutions to problems
means for controlling computerized devices
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-6
Why Study Programming Languages?
• Increased ability to express ideas
– New paradigms and ways of thinking
• Improved background for choosing appropriate
languages
• Greater ability to learn new languages
• Understand significance of implementation
– why is recursion slow? How are data structures implemented?
• Ability to design new languages
• Overall advancement of computing
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-7
Why Study Programming Languages?
• Computing techniques in general, and
programming languages in particular, are
changing so quickly that detailed knowledge of a
given programming language becomes obsolete in
a decade.
• Computer science is not defined by the number of
different programming languages you "know“,
however.
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-8
Why Study Programming Languages?
• A computing professional knows:
–
–
–
–
the concepts of problem solving and algorithms
the techniques of developing large applications
how the machine and an operating system work
how to look up and understand the relevant syntactic
details of a language
– the fundamental characteristics of language paradigms
– which language paradigm is designed to work best with
which kind of problem/task
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-9
Why Study Programming Languages?
• To start using a new programming language, a
good computing professional needs
– an understanding of the concepts described on the
previous slide
– a manual
– a few hours to experiment with the
compiler/interpreter
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-10
Course Goals
• To try to understand the fundamental structural
issues that lead programming languages to be
what they are...
• Provide foundational insights to help in
understanding programming languages of the
future (…not how to program competently in a
dozen different languages)...
• Provide basic insights in programming language
implementation (…not to teach you how to write
interpreters and compilers)...
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-11
Course Goals
• major paradigms (conceptual basis)
• language design
–
–
–
–
data types
control structures
data flow
run-time behavior
• semantic and syntactic notations
– grammars
– expressions
• implementation issues
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-12
Programming Domains
• Scientific applications
– Large number of floating point computations (Fortran)
• Business applications
– Produce reports, use decimal numbers and characters (COBOL)
• Artificial intelligence
– Symbols rather than numbers manipulated (Lisp)
• Systems programming
– Need efficiency because of continuous use (C, C++)
• Scripting languages
– Put a list of commands in a file to be executed (Perl, JavaScript,
PHP)
• Special-purpose languages (SNOBOL, APL)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-13
Language Evaluation Criteria
Criteria
ch aracte ris ti c
Re adabi li ty
W ri te abil ity
Re li abil ity
Simplicity/ort hogonality
•
•
•
Control struct ures
•
•
•
Dt a types & struct ures
•
•
•
Synt ax design
•
•
•
Support for abst raction
•
•
Expressivit y
•
•
T ype checking
•
Exception handling
•
Rest rict ed aliasing
•
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-14
Language Evaluation Criteria
• Readability
– The most important criterion for judging languages
• writing code is only a small part of software engineering!
• before the 1970’s emphasis was on machine view of lang:
– efficiency
– machine readability
• Now recognize that maintenance is more important
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-15
Language Evaluation Criteria
• Readability
– Factors:
• Overall simplicity
– Too many features is bad (large learning curve)
– Too few features is bad (e.g., assembly language)
– Multiplicity of features is bad (more than one way to do something)
count = count + 1; count += 1; count++; ++ count;
all do (basically) the same thing.
– Operator Overloading
» can reduce readability if users overload too much
» What is overload + to mean sum all elements of 2 arrays?
This is not normal meaning of vector addition!
– Regularity (rules with no exceptions) is good!
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-16
Language Evaluation Criteria
• Readability
• Orthogonality
– A small set of primitive constructs can be combined in a relatively
small number of ways to build the control and data structures of the
language.
– every possible combination of primitives is legal and meaningful.
– example:
» four primitive types: int, float, double, char
» two type operators: array, pointer
» type operators can be applied to themselves and the
primitives.
» if did not allow pointers to point to arrays, would limit the
possible data structures.
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-17
Language Evaluation Criteria
• Readability
• Orthogonality
– Makes the language easy to learn and read
– Meaning is context independent
– A relatively small set of primitive constructs can be combined in a
relatively small number of ways
– Every possible combination is legal
– Lack of orthogonality leads to exceptions to rules
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-18
Language Evaluation Criteria
• Readability
• Orthogonality example (C language):
–
–
–
–
–
Why can structs be returned from functions but not arrays?
Why can a member of a struct not be another struct or a void?
Why can an array element not be a function or a void?
Why are all parameters pass by value except arrays?
If you add x + y and x is a pointer (that is 2 bytes long), then y’s
value is multiplied by 2 before addition takes place (assumes y is
also a pointer!)
• Too much orthogonality (ALGOL 68)
– Can have any statement on left hand side of an assignment (even if
statements!)
• Good orthogonality: functional languages (Lisp, ML, etc.)
– everything is a function. No assignment operators.
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-19
Language Evaluation Criteria
• Readability factors (continued)
– Control statements
• avoiding goto’s
– Defining data types and structures
• proper types/structures for the problem domain
• Example: easier to understand code if there is a
Boolean type instead of using numbers
• Records make it easy to aggregate related data
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-20
Language Evaluation Criteria
• Readability factors (continued)
– Syntax considerations
• Identifier forms: long identifiers are easier to read
• Special words
– readability influenced by words like while for class etc.
– special words to end control statements (like end for or
end if) make a language easier to read
• Form and meaning
– symantics should follow from syntax
– special words should indicate use
– never use special words for two different meanings (like
static in C; can use inside functions to create a var at
compile time or outside a function to restrict to a file).
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-21
Language Evaluation Criteria
• Writability
– a measure of how easily a language can be used to
create programs for a chosen problem domain.
– must compare language writability in context of target
problem domain
• COBOL and Fortran are better for different domains
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-22
Language Evaluation Criteria
• Writability
– Factors:
• Simplicity and orthogonality
– large languages hard to understand and use correctly
– better to have small number of primitive constructs and
consistent set of rules (orthogonality)
– too much orthogonality: anything goes; hard to catch mistakes
• Support for abstraction
–
–
–
–
ability to hide detail
two areas of abstraction: process and data
process: subprograms and modules
data: struct’s, records, objects
• Expressivity
– shortcuts (x++ instead of x = x + 1;)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-23
Language Evaluation Criteria
• Reliability
– A reliable program performs to its specifications under
all conditions.
– Factors:
•
•
•
•
Type checking
Exception handling
Aliasing
Readability and writability
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-24
Language Evaluation Criteria
• Reliability
– Factors:
• Type checking
• Exception handling
– present in Ada, C++, Java, not in C or Fortran
• Aliasing
– two variables point to same memory (thing pointers).
– dangerous
• Readability and writability
– writability: can force unnatural approach
– readability affects maintainability
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-25
Language Evaluation Criteria
• Cost
– Categories
• Training programmers to use language (simplicity and
orthogonality)
• Writing programs (writability and appropriateness for the
problem)
• Compiling programs (speed, accuracy, etc.)
• Executing programs (efficiency)
– compile time vs optimization
• Language implementation system (Java is free; Ada
originally expensive)
• Reliability
• Maintaining programs (readability)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-26
Language Evaluation Criteria
• Cost
– Other Categories:
• portability
• generality (good for many problem domains)
• well-definedness
– Most important Categories:
• program development
• maintenance
• reliability
– these depend on readability and writability
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-27
Language Evaluation Criteria
• There are at least 3 different points of view from
which to consider a programming language:
– designer
(the inventor of the language)
wants elegance
– implementer
(the compiler writer)
simplicity of implementing constructs and features
– user
(the programmer)
writability/readability
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-28
Influences on Language Design
• Computer architecture: Von Neumann
• See next slide
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-29
Von Neumann Architecture
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-30
Influences on Language Design
• 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 efficient (instr next to each other in mem)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-31
Influences on Language Design
• functional languages
– primary means of computation is applying functions
to parameters
– no use of variables, assignment statements, iteration
– problem: von Neumann architecture is not efficient
for implementing functional languages
– e.g., recursion is expensive
– parallel architectures still imperative (use Fortran!)
– no architecture for functional languages
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-32
Influences on Language Design
• Programming methodologies
– 1950s and early 1960s: Simple applications; worry
about machine efficiency
– Late 1960s: People efficiency became important;
readability, better control structures
• Structured programming
• Top-down design and step-wise refinement
• reaction to incomplete type checking and poor control
(goto’s)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-33
Influences on Language Design
• Programming methodologies
– Late 1970s: Process-oriented to data-oriented
• data abstraction (ADT, modules)
• SIMULA 67 first lang to support data abstraction
– Middle 1980s: Object-oriented programming
•
•
•
•
encapsulation, inheritance, dynamic method binding
Smalltalk first pure OOP language (1989)
easy to support in imperative lang: C++, Ada 95, Java
also in LISP (CLOS, 1988) and in Prolog++ (1994)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-34
Influences on Language Design
• Programming methodologies
– current: concurrency
• Muli-core architectures
• support in Ada and Java
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-35
Language Categories
• Imperative
– Central features are variables, assignment
statements, and iteration
– C, Pascal, Ada
• Functional
– Main means of making computations is by
applying functions to given parameters
– LISP, Scheme, ML, Haskell
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-36
Language Categories
• Logic
– Rule-based
– Rules are specified in no special order
– Prolog
• Object-oriented
–
–
–
–
Encapsulate data objects with processing
Inheritance and dynamic type binding
Grew out of imperative languages
C++, Java, Ada 95
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-37
Language Categories
• Parallel Languages
– Support to easily create threads that can execute in parallel
– Must also support coordination and sharing
• Visual Languages (4th Generation Lang)
– Visual BASIC, Visual BASIC .net
– drag-and-drop generation of code segments
– makes it easy to generate graphical user interfaces to
programs.
• Mark-up languages
–
–
–
–
HTML, XML
do not specify computations, therefore are not PL
design, evaluation, implementation similar to PL
not discussed in this course
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-38
Language Design Trade-Offs
• Reliability vs. cost of execution
– array bounds checking (Java, not C)
– including raises reliability, lowers efficiency
• Readability vs. writability
– APL has many built-in functions (with special symbols)
– easy to write, hard to read
– Perl has similar problems
• Flexibility vs. safety
– variant records. Can store different values in same field.
– flexible, but dangerous at run time.
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-39
Layered View of Computer
• machine language (macroinstructions)
– provides primitive instructions
• operating system
– supplies higher-level primitives
– for resource management,input/output, file
management, text editors, etc.
• language implementations (compilers)
– provides virtual computer
– provides interface between programmer and the
virtual computer (OS + machine)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-40
Layered View of Computer
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-41
Implementation Methods
• Compilation
–
–
–
–
Translate high-level program to machine code
Slow translation
Fast execution
used for most production languages (C, C++, Ada,
COBOL, Pascal)
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-42
groups characters of
source program into
tokens: identifiers,
operators, punctuation
constructs hierarchical
structures called parse
trees that represent
the syntactic structure
checks
for semantic
of the program
symbol table contains
errors (like type errors)
type and attribute info
and creates intermediate
about all user-defined
code (higher level than
variables
assembly)
Compilation
Process
(parser)
machine program must
be linked to OS programs
(like I/O libs) and loaded
into memory.
machine prog + OS code
= load module
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-43
Implementation Methods
• Pure interpretation
– No translation
– programs are interpreted by another program
• provides a software simulation of a machine
– Slow execution (10-100X slower)
– every time the same line is executed, must be decoded.
– requires more space during execution
• symbol table and source code must be available.
– easier to debug: all run-time errors occur immediately after
the line is executed.
– Becoming rare
• early LISP, APL, SNOBOL
• Now: JavaScript, PHP
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-44
Pure Interpretation
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-45
Implementation Methods
• Hybrid implementation systems
– translate high-level language programs to an
intermediate language
– this language is then interpreted
– faster than pure interpretation because source code
is decoded only once.
– Perl, some Java (like applets that use a VM).
• some Java applications are now compiled
– Small translation cost
– Medium execution speed
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-46
Hybrid
Implementation
System
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-47
Programming Environments
• The collection of tools used in software development
• UNIX
– An older operating system and tool collection
– separate tools: file system, text editor, compiler, debugger,
linker
• Borland Jbuilder, C++ Builder, Delphi
– An integrated development environment for Java
• Microsoft Visual Studio.NET
– A large, complex visual environment
– Used to program in C#, Visual BASIC.NET, Jscript, J#, or
C++
• IBM Eclipse
– Open source
Copyright © 2004 Pearson Addison-Wesley. All rights reserved.
1-48