Lecture 1: Introduction Course administration After the PLC course ...

Lecture 1: Introduction • • • • • • • •

Course administration Goals of the course Why study programming language concepts and theory? Influences on language design - brief history Language categories / paradigms Programming domains Language implementation Language evaluation criteria

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

1

Course administration • Two coordinated courses!

 Programming Language Concepts  Programspråk

• Teachers • • • •

Lennart Edblom (lectures, main responsible PLC) Anders Broberg (lectures, main responsible PS) Linus Jonsson (exercises, labs PLC) Lars Karlsson (exercises, labs PS)

• Textbook(s)

 Sebesta: Concepts of Programming Languages, 8:th (7:th) edition, Pearson Education (BOTH)  Hansen, Rischel: Intro to programming using SML, Addison-Wesley 1999 (PS)  Excerpts from Stansifer: The study of programming languages (PLC) (provided by the teacher)

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

2

After the PLC course, you should • Have knowledge about important programming language paradigms (also PS) • Understand the concepts languages are based on, and how they can be implemented (also PS) • Know about methods to define the syntax and semantics of programming languages, be able to understand such definitions (not PS) • Be able to evaluate languages / language concepts and choose what is most appropriate for different problems and applications (also PS)

This course is neither a programming course nor a compiler course 2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

3

After the PS course you should also • have an in-depth knowledge about the functional programming paradigm • be able to design recursive algorithms and data types • be able to implement these algorithms and data types in a functional programming language

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

4

Course evaluation from previous year • Book OK, but could be more concise. Other material good, (but maybe too much?). Most powerpoint slides good, a few incomprehensible. • Good labs, good complement to the theory. The first difficult(?), the second a bit (too?) simple. • Lectures; basically good. Could be speeded up? • Difficulty; ”lagom”, i.e. not too easy, not to difficult • The beginning is theoretical (=difficult?), but not the second half

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

5

Why programming language concepts? It is not enough to be able to program. You become a Computer Scientist only when you can reflect about how things are connected and how they work. To consider a subject with a scientific approach demands that you have the ability to • Formulate the general principles that it is based on • Understand the fundamental ideas • Be aware of the pros and cons of different alternatives • Give your own contributions to the development, in the long run. 2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

6

Why P.L. concepts? (cont.) More practical motivations are to • get access to a larger set of problem solving tools • improve your ability to learn / choose /develop programming languages • be able to avoid programming errors that are caused by ”dangerous” concepts or mixing different concepts • be able to write better (e.g. more efficient) programs by knowing how they are affected by implementation issues Furthermore: The more people that are better educated, the larger is the chance that new and better concepts will gain acceptance. 2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

7

Influences on Language Design • Computer architecture: Von Neumann • We use imperative languages, at least in part, because we use von Neumann machines (next slide) 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

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

8

Von Neumann Architecture

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

9

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

 Late 1970s: Process-oriented to data-oriented • data abstraction

 1980s: Functional programming, Logic programming  Middle 1980s: Object-oriented programming  Concurrency (“multicore”)

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

10

Language categories / paradigms Imperative languages  Instr. transform the contents of memory cells step by step  oriented towards von Neumanns computer arch. (fig 1.1)

Functional languages  specify and apply functions similar to mathematics  abstracts away from the computer

Logic programming languages  specify ground truths (facts) and their relation  use logical inference rules to deduct new facts

Object oriented languages  the fundamental concept is ”objects” which ”communicate” with each other  often an imperative language, basically 2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

11

Programming domains Scientific applications → efficiency, fast floating-point arithmetic (first language: FORTRAN)

Business applications → decimal arithmetic, producing elaborate reports (first language: COBOL)

Artificial intelligence → symbolic computations, lists of data (first language: LISP, later: PROLOG)

Systems programming → efficiency, direct access to resources of the operating system (early language: PL/I (PL/S), later: C)

Miscellaneous (markup languages, scripting languages, web software etc) 2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

12

Layered View of Computer

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

13

Implementation Methods • Compilation  Translate high-level program to machine code  Slow translation  Fast execution

• Pure interpretation  No translation  Slow execution  Common => Rare => now gaining ground againg

• Hybrid implementation systems  Small translation cost  Medium execution speed

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

14

Compilation Process

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

15

Pure Interpretation

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

16

Hybrid Implementation System

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

17

Programming Environments • The collection of tools used in software development • UNIX  An older operating system and tool collection

• Borland JBuilder

 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++

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

18

Language evaluation criteria Is a langua

ge /langua ge co

Readability

ncept good

?

 How easy is it to understand what the program does?  Decisive factor for software maintenance  Has influence on all other criteria

Writeability  How easy is it to write a program? To formulate / express the problem and its solution?  Writing programs is the basic motivation for developing programming languages  A language can have different writeability for different application areas  No writeability without readability 2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

19

Language evaluation criteria (2) Reliability  Are programs doing what they are supposed to do?  No reliability without readbility and writeability  The most important criterion for some applications

Costs, which can be caused by  Training programmers, writing, using and maintaining programs  Implement the language, compile programs  Execute programs (efficiency)

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

20

Characteristics that have a significant effect on readability Simplicity

 The number of concepts /features.  Feature multiplicity. How many ways can the same thing be expressed?  Sensible use of operator overloading.

Orthogonality

 A relatively small set of primitive constructs can be combined in a relatively small number of ways. All combinations are legal. Increases readability (but not when used in excess)

Control statements

 Good structure is more important than maximum flexibility.

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

21

Characteristics that have a significant effect on readability (2) Data types and data structures  Adequate facilities for defining (your own) datatypes a must (orthogonality!)  ”Natural” representation of data

Syntax  what identifiers are allowed?  The syntax of the language should be natural an easy to interpret (correctly) (form and meaning harmonize)

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

22

Characteristics that have a significant effect on writeability Simplicity and orthogonality

 Learn a few fundamental concepts and rules for combining them and you know the language!

Support for abstraction

 Concepts that allow you to focus on different levels  Possible to decompose problems  Both process and data abstraction are important

Expressibility

 Powerful concepts/features increases expressibility (but may decrease readability!)

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

23

Features that have a significant effect on reliability Type checking  type errors indicate bad or sloppy programming style  preferably compile-time type checking

Exception handling  simple and powerful means for detecting and handling errors  recovery after taking corrective measures

Aliasing, pointers / references  what are they allowed to refer to?  aliases - a dangerous feature  explicit deallocation makes certain errors possible 2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

24

Simple answers are missing!!! The criteria sometimes conflicts with one another. To find the best compromise you have to weigh different perspectives. Examples: • simplicity (readability) vs expressivity • reliability vs efficiency • flexibility vs security

2 0 0 8 -1 1 -0 7

Lennart Edb lom , Inst. f. d atavetenskap

25