Programming Language Paradigms February.ppt

CS 152: Programming Language
Paradigms
February 5 Class Meeting
Department of Computer Science
San Jose State University
Spring 2014
Instructor: Ron Mak
www.cs.sjsu.edu/~mak

SJSU Dept. of Computer Science
Spring 2014: February 5
CS 152: Programming Language Paradigms
© R. Mak
2
Language Syntax
 Example: Syntax of the Java if statement:
 This syntax rule is written in English.
 Later, we’ll use a more precise notation called
Backus Naur Form (BNF).
_
An if statement consists of the reserved word if
followed by a left parenthesis followed by an
expression followed by a right parenthesis
followed by a statement. Optionally, this is
followed by the else part which consists of the
reserved word else followed by a statement.

© R. Mak
3
Language Semantics
 Semantics: The meaning of a language’s statements.
 What is the effect of executing the statement at run time?
 It can be difficult to provide a comprehensive description
of meaning in all contexts.
 Example: Semantics of the Java if statement:
First evaluate the expression following the
reserved word if. If the expression’s value is true,
then execute the statement following the expression,
otherwise skip over the statement. If there is an
else part, execute the statement following the
reserved word else if the expression’s value is false,
otherwise skip over that statement.

© R. Mak
4
Syntax and Semantics
 How are a language’s syntax and semantics used?
 A well-specified syntax allows programs in the language
to be automatically read and translated.
 Well-understood semantics allows the program to be
translated into a equivalent program.
 Equivalent programs have similar runtime behaviors.
_

© R. Mak
5
Programming Language Translation
 There are two major types of language translators:
 compiler
 interpreter
 Source program: The program to be translated,
written in a high-level programming language.
 Example: A Java program.
_

© R. Mak
6
Programming Language Translation
 Both types of language translators will read
a source program and ...
 Check the program for syntax errors.
 Convert the program into
 Intermediate code, such as tree structures (parse trees)
 Symbol tables that contain information about
the program’s named elements, such as its variables.
 An interpreter can then use the intermediate code and
the symbol tables to execute the program.
_

© R. Mak
7
Compilers
 A compiler takes the intermediate code and the symbol
tables and generates a lower-level form of the program.
 This lower-level form is closer to machine language.
 Example: An equivalent assembly language program.
 Target language: The language that a compiler
translates a source language into.
 Example: Assembly language
 Other tools, such as an assembler, translates the compiler’s
target language into machine language code.
_

© R. Mak
8
Compilers
 Object code: The machine language code
generated by an assembler.
 The object code can then linked with other object code
and then loaded into memory for execution.
_

© R. Mak
9
Compiler
Interpreter
Compiler and Interpreter
Compilers and Interpreters
Front-end
translator
Intermediate
code
Symbol
tables
Assembly
code
Assembler
Machine
code
Execution
Code
generator
Executor
Source
program
Execution Program executes under the
control of the interpreter.
Program executes
on its own.

© R. Mak
10
 A compiler generates object code,
but an interpreter does not.
 Executing the source program from object code can be
several orders of magnitude faster than executing the program
by interpreting the intermediate code and the symbol table.
 But an interpreter requires less effort to get a source program
to execute = faster turnaround time.
 An interpreter maintains control
of the source program’s execution.
 Interpreters often come with interactive source-level debuggers
that allow you to refer to source program elements, such as
variable names.
 AKA symbolic debugger
_

© R. Mak
11
 Therefore ...
 Interpreters are useful during program development.
 Compilers are useful to run released programs
in a production environment.
_

© R. Mak
12
The Future of Programming Languages
 In the 1960s, computer scientists wanted a single
universal programming language to meet all needs.
 In the late 1970s and early 1980s, they wanted
specification languages that would allow users
to define the needs and then generate the application.
 Tell the system what you want it to do.
 The system figures out how to do it.
 This is what logic programming languages attempt to do
 Programming has not become obsolete.
 New languages arise to support new technologies.
 Example: Web programming.

© R. Mak
13
Popularity of Programming Languages

© R. Mak
14
Popularity of Programming Languages, cont’d

© R. Mak
15
Popularity of Programming Languages, cont’d
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

© R. Mak
16
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.
_

© R. Mak
17
Good Programming Language Design, cont’d
 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
_

© R. Mak
18
Historical Overview
 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.

© R. Mak
19
Historical Overview, cont’d
 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.
_

© R. Mak
20
 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
_

© R. Mak
21
 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
_

© R. Mak
22
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.
_

© R. Mak
23
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.
_

© R. Mak
24
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.
_

© R. Mak
25
Regularity, cont’d
 Regularity involves three concepts:
 Generality
 Orthogonal design
 Uniformity
 Otherwise classify a feature or construct as irregular.
_

© R. Mak
26
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.
_

© R. Mak
27
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.

© R. Mak
28
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.
_

© R. Mak
29
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.
 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.

© R. Mak
30
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.
_

Programming Language Paradigms February.ppt

More Related Content

Similar to Programming Language Paradigms February.ppt

Recently uploaded

Programming Language Paradigms February.ppt