Chapter 1

1. Chapter 1 Preliminaries

2. Purpose of This Book • To examine carefully • the underlying concepts of the various constructs and capabilities of programming languages

3. Chapter 1 Topics • Reasons for Studying Concepts of Programming Languages • Programming Domains • Language Evaluation Criteria • Influences on Language Design • Language Categories • Language Design Trade-Offs • Implementation Methods • Programming Environments

4. Reasons for Studying Concepts of Programming Languages (1) • Increased ability to express ideas • The depth at which people can think is influenced by the expressive power of the language in which they communicate their thoughts • The language in which programmers develop software places limits on the kinds of control structures, data structures, and abstraction they can use • Awareness of a wider variety of programming language features can reduce such limitations in software development • Languages constructs can be simulated in other languages that do not support those constructs directly; however, the simulation is often less elegant, more cumbersome, and less safe.

5. Reasons for Studying Concepts of Programming Languages (2) • Improved background for choosing appropriate languages • Increased ability to learn new languages • According to TIOBE, Java, C, and C++ were the three most popular languages in use in Jan. 2007.

6. Reasons for Studying Concepts of Programming Languages (3) • Better understanding of significance of implementation • Program bugs • Performance • Better use of languages that are already known • Overall advancement of computing • Those in positions to choose languages wer not sufficiently familiar with programming language concepts

7. Programming Domains (1) • Scientific applications • Large number of floating point computations • Simple data structures • Fortran • Originally developed by IBM in the 1950s • Business applications • Facilities for • producing elaborate reports, • Storing decimal numbers and character data • The ability to specify decimal arithmetic operations • COBOL • The initial version appeared in 1960 • Artificial intelligence • Symbols, consisting of names rather than numbers, are manipulated • LISP • Appeared in 1959

8. Programming Domains (2) • Systems programming • The operating system and all of the programming support tools of a computer system are collectively known as its systems software. • Systems software is used almost continuously and so must be efficient. • A language for this domain must provide • fast execution • having low-level features that allow the software interfaces to external devices to be written • C • The UnixOS is written almost entirely inC

9. Programming Domains (3) • Web Software • Eclectic collection of languages: markup (e.g., XHTML), scripting (e.g., PHP), general-purpose (e.g., Java)

10. Language Evaluation Criteria • Readability: the ease with which programs can be read and understood • Writability: the ease with which a language can be used to create programs • Reliability: conformance to specifications (i.e., performs to its specifications) • Cost: the ultimate total cost

11. Why Readability Is Important • Maintenance was recognized as a major part of the software life cycle, particularly in terms of cost. • Ease of maintenance is determined in large part by the readability of programs.

12. Characteristics Contributing to the Readability - Simplicity • Overall simplicity • A manageable set of features and constructs • Readability problems occur whenever the program’s author has learned a different subset from that subset with which the reader is familiar. • Few feature multiplicity (methods of doing the same operation) • For example, in Java the following ways could be used to increase a integer variable count = count + 1 count += 1 count++ ++count • Minimal operator overloading (a single operator symbol has more than one meaning) • Overloading may simplify a language by reducing the number of operators; however, it can lead to reduced readability if users are allowed to create their own overloading and do not do it sensibly.

13. Excessive Simplicity • Simplicity improves readability; however, excessive simplicity may also reduce readability. • For example: • The form and meaning of most assembly language statements are models of simplicity. • This very simplicity, however, makes assembly language programs less readable. Because they lack more complex control statements, program structure is less obvious.

14. Characteristics Contributing to the Readability - Orthogonality • Orthogonality • A relatively small set of primitive constructs can be combined in a relatively small number of ways • Every possible combination is legal and meaningful • e.g. • Suppose a language has four primitives data types (integer, float, double, and character) and two type operators (array and pointer) • If the two type operators can be applied to themselves and the four primitive data types, a large number of data structures can be defined.

15. Influence of Lacking Orthogonality • The lack of orthogonality leads to exceptions to the rules of the language. • For example: • Pointers should be able to point to any type of variable or data structure. • If pointers were not allowed to point to arrays, many of those possibilities would be eliminated.

16. Orthogonality Example • IBM A Reg1, memory_cell AR Reg1, Regs [corresponding Semantics] Reg1 <- contents(Reg1)+ contents(memory_cell) Reg1 <- contents(Reg1)+ contents(Reg2) • VAX( instruction design is ortogonal) ADDL operand_1, operand_2 [corresponding Semantics] Operand_2 <- contents(operand_1)+contents(opernad_2)

17. Orthogonality vs. Simplicity • Orthogonality is closely related to simplicity • The more orthogonal the design of a language, the fewer exceptions the languages rules require. • Fewer exceptions mean a higher degree of regularity in the design, which makes the language easier to learn, read, and understand.

18. Is Orthogonality Always Good? • Too much orthogonality can also cause problems, because they make a programming language too complicated. • Example: • ALGOL 68 • Every language construct in ALGOL 68 has a type • There are no restrictions on those types • Most construct produce values

19. Characteristics Contributing to the Readability – Control Statements • The presence of well-known control structures (e.g., while statement) • A program that can be read from top to bottom is much easier to understand than a program that requires the reader to jump from one statement to some nonadjacent statement in order to follow the execution order.

20. Characteristics Contributing to the Readability - Data Types and Structures • The presence of adequate facilities for defining data structures • Example: • If a language doesn’t have a Boolean type, then it may need to use a numeric type as an indicator flag timeOut =1 • Comparing with a language providing Boolean type, the following state is much more readable timeOut = true

21. Characteristics Contributing to the Readability - Syntax Considerations (1) • Identifier forms: flexible composition • Restricting identifiers to very short lengths detracts form readability

22. Characteristics Contributing to the Readability - Syntax Considerations (2) • Special words • Program appearance and thus program readability are strongly influenced by the forms of a language’s special words • Whether the special words of a language can be used as names for program variables? • methods of forming compound statements • C and its descendants use braces to specify compound statements. • All of these languages suffer because statements groups are always terminated in the same way, which makes it difficult to determine which group is being ended when and end or } appears.

23. Characteristics Contributing to the Readability - Syntax Considerations (3) • Form and meaning: self-descriptive constructs, meaningful keywords

24. Evaluation Criteria: Writability • Writability is a measure of how easily a language can be used to create programs for a chosen problem domain. • Most of the language characteristics that affect readibility also affect writability. • This follows directly from the fact that the process of writing a program requires the programmer frequently to reread the part of the program that is already written

25. Writability Comparison between Two Different Languages • It is simply not reasonable to compare the writability of two languages in the realm of a particular application when one was designed for that application and the other was not.

26. Characteristics Contributing to the Writability -Simplicity and Orthogonality • Few constructs, a small number of primitives, a small set of rules for combining them • A large number of different constructs may lead to a misuse of some features and a disuse of others hat may be either more elegant of more efficient, or both, than those that are used • On the other hand, too much orthogonality can be a detriment to writability • Errors in programs can go undetected whennearly any combination of primitives is legal

27. Characteristics Contributing to the Writability - Support for Abstraction • Abstraction - the ability to define and usecomplex structures or operations in ways that allow details to be ignored • Programming languages can support two distinct categories of abstraction: • Process • Data

28. Process Abstraction • A simple example of process abstraction is the use of a subprogram to implement a sort of algorithm that is required several times in a program.

29. Data Abstraction • A binary tree • Fortran 77 – use parallel integer arrays to implement • C++ and Java – use a class with two pointers (or references) and an integer

30. Characteristics Contributing to the Writability - Expressivity • A set of relatively convenient ways of specifying operations • Example: • the inclusion of for statement in many modern languages makes writing counting loops easier than with the use of while.

31. Evaluation Criteria: Reliability • A program is said to be reliable if it performs to its specifications under all conditions.

32. Characteristics Contributing to the Reliability – Type Checking • Testing for type errors in a given program, either by the compiler or during program execution. • Run-time type checking is expensive • Compile-time type checking is more desirable • The earlier errors in programs are detected, the less expensive it is to make the required repairs • Example int foo(unsigned int a, int b) { … } void bar() { w=foo(-1,2); }

33. Characteristics Contributing to the Reliability – Exception Handling • Exception handling • Intercept run-time errors and take corrective measures and then continue the corresponding program’s execution

34. Characteristics Contributing to the Reliability – Aliasing • Presence of two or more distinct referencing methods for the same memory location • It is now widely accepted that aliasing is a dangerous feature in a programming language • Most programming languages allow some kind of aliasing – for example, two pointers set to point to the same variable.

35. Characteristics Contributing to the Reliability – Readability and Writability • Readability and writability • A language that does not support “natural” ways of expressing an algorithm will necessarily use “unnatural” approaches, and hence reduced reliability

36. Evaluation Criteria: Cost • Training programmers to use language • Writing programs Compiling programs • Executing programs • Language implementation system: availability of free compilers • Reliability: poor reliability leads to high costs • Maintaining programs

37. Evaluation Criteria: Others • Portability • The ease with which programs can be moved from one implementation to another • Generality • The applicability to a wide range of applications • Well-definedness • The completeness and precision of the language’s official definition

38. Influences on Language Design • Computer Architecture • Languages are developed around the prevalent computer architecture, known as the von Neumann architecture • Programming Methodologies • New software development methodologies (e.g., object-oriented software development) led to new programming paradigms and by extension, new programming languages

39. Von Neumann Architecture • Most of the popular languages of the past 50 years have been designed around the prevalent computer architecture: Von Neumann architecture • These language are called imperative languages. • Data and programs are stored in the same memory • Memory is separate from CPU • Instructions and data are transmitted from memory to CPU • Results of operations in the CPU must be moved back to memory • Nearly all digital computers built since the 1940s have been based on the von Neumann architecture

40. The Motherboard of a Computer

41. The von Neumann Architecture

42. Central Features of Imperative Languages • Variables: model memory cells • Assignment statements: model piping • Iteration is fast on von Neumann computers because instructions are stored in adjacent cells of memory and repeating the execution of a section of code requires only a simple branch instruction

43. Program Execution on a Von Neumann Computer • The execution of a machine code program on a von Neumann architecture computer occurs in a process called the fetch-execute cycle. • Each instruction to be executed must be moved from memory to the processor. • The address of the next instruction to be executed is maintained in a register called the program counter.

44. Fetch-execute-cycle (on a von Neumann Architecture) initialize the program counter repeat forever fetch the instruction pointed by the counter increment the counter decode the instruction execute the instruction end repeat P.S.: the ``decode the instruction’’ step in the algorithm means the instruction is examined to determine what action it specifies.

45. Functional Language Programs Executed on a Von Neumann Machine • A functional language is one in which the primary means of computation is applying functions to given parameters. • Programming can be done in a functional language without the kind of variables that are used in imperative languages, without assignment statements, and without iteration. • Although many computer scientists have expounded on the myriad benefits of functional languages, it is unlikely that they will displace the imperative language until a non-von Neumann computer is designed that allows efficient execution of programs in functional languages

46. Evolution of Programming Methodologies (1) • 1950s and early 1960s: • Simple applications • worry about machine efficiency • 1970s: • Hardware costs decreased • programmer costs increased • Larger and more complex problems were being solved by computers • Emphasis: • structured programming • top-down design and step-wise refinement • Deficiency: • Incompleteness of type checking • Inadequacy of control statements • Requiring the extensive use of gotos

47. Evolution of Programming Methodologies (2) • Late 1970s: • shift from procedure-oriented to data-oriented • Emphasize data design, focusing on the use of abstract data types to solve problems • Most languages designed since the late 1970s support data abstraction • Middle 1980s: Object-oriented programming • data abstraction • encapsulates processing with data objects • controls access to data • Inheritance • Enhances the potential reuse of existing software, thereby providing the possibility of significant increases in software development productivity • dynamic method binding • Allow more flexible use of inheritance

48. Object-oriented Programming and Languages • First language supporting its concepts: Smalltalk. • Support for object-oriented programming is now part of most popular imperative language, including • Ada 95, Java, and C++ • Object-oriented concepts have also found their way into • Functional programming in CLOS • Logical programming in Prolog++

49. All of the evolutionary steps in software development methodologies led to new language constructs to support them.

50. Programming Language Categories • Imperative • Central features are variables, assignment statements, and iteration • Examples: C, Pascal • Functional • Main means of making computations is by applying functions to given parameters • Examples: LISP, Scheme • Logic • Rule-based (rules are specified in no particular order) • Example: Prolog • Object-oriented • Data abstraction, inheritance, late binding • Examples: Java, C++