Introduction. Definitions History of programming languages Design issues Implementation issues Programming paradigms. TUT Pervasive Computing

Transcription

1 Introduction Definitions History of programming languages Design issues Implementation issues Programming paradigms 1

2 Attempts to define a programming language A tool for humans to tell the computer what to do A means of formal communication between humans A way of describing an abstract machine A way of describing computation in the form that is readable both for a machine and for a human 2

3 Motivation Reasons to study principles of programming languages learning new languages more easily borrowing ideas from other languages ability to express ideas choosing an appropriate programming language understanding the significance of implementation designing your own programming language 3

4 MOTTO "Good engineering involves compromise at every turn. A good, working, finished product is never pure by the standards of any one idiom or methodology. The art of good engineering is not the art of discovering and applying the one right idiom over all others. The art of good engineering is to know what your options are, and then to choose your trade-offs wisely rather than letting others choose them for you." 4

5 Compromises in programming languages Expressiveness efficiency Intuitiviness implementation Intuitiviness unambiguousness Unambiguousness optimisation Flexibility checkability Portability efficiency Generality ease of expression Generality suitability to a domain 5

6 History of programming languages No language exist in vacuum, but languages are often based on other languages steal features from other languages try to steel programmers from other languages try to fix stupid features in other languages 6

7 Family tree of programming languages COBOL FORTRAN I PL/I FORTRAN IV CPL BASIC ALGOL C ALGOL 68 SIMULA I SIMULA 67 PASCAL MODULA-2 ADA 83 SmallTalk SMALLTALK C++ FORTRAN 90 OBERON VISUAL BASIC JAVA MODULA-3 EIFFEL ADA 95 LISP SCHEME COMMON LISP COMMON LISP / CLOS PROLOG C# PROLOG++ 7

8 Evolution of programming languages 1. Detection of a recurring structure or a need for a particular expression 2. Abstraction What is an essential need? 3. Developing a concrete expression to fulfill the need Assembly: Fortran: LDX... CMPX... JG... 1: IF ( expr ) GOTO 2... GOTO 1 2:... IF ( expr ) GOTO address WHILE expr DO... Algol Fortran 8

9 Programming language design Characteristics Criteria Readability Writeability Reliability 1. Simplicity 2. Orthogonality 3. Control structures 4. Data types 5. Syntax design 6. Expressivity 7. Support for abstraction 8. Type checking 9. Correctness 9

10 1. Simplicity Readability Writeability Reliability Small number of basic components from a large language programmers tend to learn only a subset Only one way to accomplish a particular operation Only one meaning for each operator symbol Operator overflow Apparent simplicity: small language large library Carrying simplicity too far decreases readability e.g. assembly 10

11 2. Orthogonality Readability Writeability Reliability Relatively small set of primitive constructs can be combined in a relatively small number of ways language primitives are independent of each other any combination of the primitives is legal closely related to simplicity An orthogonal language lacks exceptions An example: 4 types: integer, float, double, character 2 type operators: array and pointer each operator can be applied to each other and to all types Too much orthogonality leads to complexity e.g. Algol68 each language structure has a type and produces a value 11

12 3. Control structures Readability Writeability Reliability Structured programming avoiding goto statements Which control structures should be in a language what is a sufficient amount 12

13 An example on control structures Readability Writeability Reliability Nested loops: while ( incr < 20 ) { while ( sum <= 100 ) { sum += incr; } incr++; } The same program without while: loop1: if ( incr >= 20 ) goto out; loop2: if ( sum > 100 ) goto next; sum += incr; goto loop2; next: incr++; goto loop1; out: C code 13

14 4-5. Data types and syntax Readability Writeability Reliability Data types e.g. boolean e.g. records Syntax consideration length of identifiers special words / reserved words timeout = 1 timeout = true support for identification of control structures single (unambiguous) meaning 14

15 6. Expressivity Writeability Reliability Language level Are the problems expressible in terms of the machine or in terms of the problem? Number of concepts too few concepts makes programming inefficient and slow too much makes it hard to learn Readability self-documenting language 15

16 Language levels Writeability Reliability Language perspective: Program perspective: language Application domain Computer high abstraction low abstraction application compiler operating system 16

17 Writeability Reliability 7. Support for abstraction Allows ignoring and hiding unnecessary details Categories for abstraction: process abstraction e.g. subprograms data abstraction e.g. modules, classes Language level influences to abstraction facilities 17

18 Reliability 8. Type checking Testing for type errors can happen at compile-time at run-time The later an error is detected, the more expensive it is to be fixed A compiler for a language can be strict (like in Ada) or permissive (like in C)

19 Reliability 9. Exception handling The ability to tackle run-time errors The ability to take corrective measures The ability to continue Other safety isssues structured programming modular programming invariant-based programming

20 Other characteristics: Support for software engineering Cost of software production training the programmers, program design, implementation, testing, maintenance Development demands in programming languages e.g. top-down design -> support for structured programming e.g. growing size of programs -> support for modularity 20

21 Other characteristics: Efficiency of implementation Perspectives: efficiency of compiler implementation efficiency of compiling efficiency of the resulting code Some things are easier (more efficient) to compile than others Things that are hard to implement are usually hard to understand (for people) 21

22 Other characteristics: Standardization Portability Offical, draft, unofficial version... ANSI, ISI, IEEE,... Sub- and supersets of a language? 22

23 Evolution of design issues Languages often evolve e.g. adding new features, correcting of old errors new versions Old programs should still be compilable and executable you cannot cancel decisions made earlier Compromises sometimes unavoidable e.g. added complexity, reduced orthogonality Deprecated/compatible features e.g. C++ auto_ptr, register-keyword 23

24 Abstract machines An (imaginary) device that allows the execution of programs in a certain language L data structures and algoritms performing the storage and execution of programs written in L Implementation of an abstract machine hardware software (compiler or interpreter) Abstract machine + machine language

25 Execution cycle of an abstract machine Fetch next instruction Start Decode Fetch operands Execute op 1 Execute op n Execute halt Store the result Stop

26 Physical machine von Neumann architecture (1940 ) RAM (Random Access Machine) Memory (stores both instructions and data) Instructions + data Results of operations CPU Arithmetic and logic unit (ALU) Control unit I/O devices TUT Pervasive 26Computing

27 Compiled vs. interpreted Compiled Static typing Machine dependent Error messages by the compiler Efficiency Interpreted Dynamic typing Portability Run-time error messages (Self-modifying code) These are the two extremes. In real languages we are often somewhere between these! 27

28 Programming paradigm An abstract concept that covers the following: 1. model of computation 2. concepts (primitive data and control structures of the language) 3. tools (data structures and algorithms) 28

29 2 ways of classifying the paradigms Division 1: Division 2: Imperative block structured (procedural) object oriented distributed (concurrent) Declarative functional logic database languages Imperative (procedural) Object oriented Functional Logic Generic Script Programming model sequential parallel 29

30 Examples of paradigms Imperative [procedural] paradigm destructive assignment, explicit control flow e.g. Fortran, Pascal, C, Ada83 Object oriented paradigm objects, creating objects, message passing, inheritance e.g. Simula 67, Eiffel, Smalltalk, Java Functional paradigm computation based on functions, no side effects e.g. Lisp, Scheme, ML, Haskell Logic paradigm logic formula, proof of formula as execution e.g. Prolog, Curry Parallel paradigm processes, synchronization, message passing e.g. Occam, SR (Synchronized Resources) 30

31 3 topics of the course Theory of programming languages syntax, BNF, semantics, structure of a language, design criteria for languages Programming issues paradigms, typing, scope of variables, variable lifetimes, parameter passing, concurrency, Popping the hood data representation, memory allocation, activation records, machine language, virtual machines, compatibility 31