CLASSIFICATION OF PROGRAMMING LANGUAGES

1. CLASSIFICATION OF PROGRAMMING LANGUAGES To facilitate discussion on any subject it is convenient to group together similar facets of the subject according to some grouping notion. Computer programming languages are no exception. • Machine, Assembler and High Level Languages • Chronological order of development • Generations • Levels of abstraction (from machine level) • Declarative v Non-declarative • Paradigms This and following slides thanks to Grant Malcolm

2. MACHINE CODE • Thus, a program running on a computer is simply a sequence of bits. • A program in this format is said to be in machine code. • We can write programs in machine code: 23fc 0000 0001 0000 0040 0cb9 0000 000a 0000 0040 6e0c 06b9 0000 0001 0000 0040 60e8

3. ASSEMBLY LANGUAGE • Assembly language (or assembler code) was our first attempt at producing a mechanism for writing programs that was more palatable to ourselves. • Of course a program written in machine code, in order to “run”, must first be translated (assembled) into machine code. movl #0x1,n compare: cmpl #oxa,n cgt end_of_loop acddl #0x1,n bra compare end_of_loop:

4. HIGH LEVEL LANGUAGE • From the foregoing we can see that assembler language is not much of an improvement on machine code! • A more problem-oriented (rather than machine-oriented) mechanism for creating computer programs would also be desirable. • Hence the advent of high(er) level languages commencing with the introduction of “Autocodes”, and going on to Algol, Fortran, Pascal, Basic, Ada, C, etc.

5. Classification of programming languages: • Machine, Assembler and High Level Languages • Chronological order of development • Generations • Levels of abstraction (from machine level) • Declarative v Non-declarative • Paradigms

6. CHRONOLOGICAL CLASSIFICATION OF PROGRAMMING LANGUAGES 1940s Prelingual phase: Machine code 1950s Exploiting machine power: Assembler code, Autocodes, first version of Fortran 1960s Increasing expressive power: Cobol, Lisp, Algol 60, Basic, PL/1 --- but most “proper” programming still done in assembly language.

7. 1970s Fighting the “software crisis”: • Reducing machine dependency – portability. • Increasing program correctness -Structured Programming, modular programming and information hiding. Examples include Pascal, Algol 68 and C.

8. 1980s reducing complexity – object orientation, functional programming. • 1990s exploiting parallel and distributed hardware (going faster!), e.g. various parallel extensions to existing languages and dedicated parallel languages such as occam. • 2000s Genetic programming languages, DNA computing, bio-computing?

9. THE SOFTWARE CRISIS • The phrase software crisis alludes to a set of problems encountered in the development of computer software during the 1960s when attempting to build larger and larger software systems using existing development techniques. • As a result: • 1.Schedule and cost estimates were often grossly inaccurate. • 2.Productivity of programmers could not keep up with demand. • 3.Poor quality software was produced. • To address these problems the discipline of software engineering came into being.

10. Classification of programming languages: • Machine, Assembler and High Level Languages • Chronological order of development • Generations • Levels of abstraction (from machine level) • Declarative v Non-declarative • Paradigms

11. LANGUAGE GENERATIONS Generation Classification 1st Machine languages 2nd Assembly languages 3rd Procedural languages 4th Application languages (4GLs) 5th AI techniques, inference languages 6th Neural networks (?), others….

12. Classification of programming languages: • Machine, Assembler and High Level Languages • Chronological order of development • Generations • Levels of abstraction (from machine level) • Declarative v Non-declarative • Paradigms

13. LANGUAGE LEVELS OF ABSTRACTION . (Bal and Grune 94) Level Instructions Memory handling Low level languages Simple machine-like instructions Direct memory access and allocation High level languages Expressions and explicit flow of control Memory access and allocation through operators Very high level languages Fully abstract machine Fully hidden memory access and automatic allocation

14. Classification of programming languages: • Machine, Assembler and High Level Languages • Chronological order of development • Generations • Levels of abstraction (from machine level) • Declarative v Non-declarative • Paradigms

15. Classification of programming languages: • Machine, Assembler and High Level Languages • Chronological order of development • Generations • Levels of abstraction (from machine level) • Declarative v Non-declarative • Paradigms

16. Programming language paradigms correspond to natural language Imperative: commands “copy the value of X into Y” Functional: noun phrases “the sum of X and Y” Logic: subject/predicate sentences (declarations) “X is greater than Y”

17. Computational Paradigms Imperative: manipulate an abstract machine • variables naming memory locations • arithmetic and logic operators • reference, evaluate, assignment operators Fits von Neumann architecture closely Key operation: assignment and control-flow

18. Computational Paradigms Functional: express problem solution as operations on data • no named memory locations • no assignment operators (no side-effects) • value binding through parameter passing Key operation: function application

19. Computational Paradigms Object-oriented: organise program as collection of interacting entities with notion of identity • data and operations encapsulated • emphasis on data abstraction Key operation: message passing

20. Computational Paradigms Logic: formally specify problem solution • program states what properties a solution must have • program does not state how to calculate solution • underlying solution engine Key operation: unification

21. SUM = 0 DO 11 K = 1, N SUM = SUM + 2 * K 11 CONTINUE sum = 0; for (k=1; k<=N; k++) sum += 2*k; sum := 0; for j :=1 to N do sum := sum + 2*k; Imperative Languages Problem: sum twice the numbers from 1 to N FORTRAN C Algol

22. class myset : public Set { public: myset() {} int sum() { int s = 0; SetEnumeration e = new SetEnumeration(this); while (e.hasMoreElements()) s += ((Integer) e.nextElement()).intValue(); return s; } } Object-oriented Languages Problem: sum twice the numbers from 1 to N C++

23. fun sum(n) = if n = 0 then 0 else 2 * n + sum (n - 1); sum(4) evaluates to 20 Functional Languages Problem: sum twice the numbers from 1 to N ML (define (sum n) (if (= n 0) 0 (+ (* 2 n) (sum (- n 1))) ) ) (sum 4) evaluates to 20 Scheme

24. sum(0,0). sum(N,S) :- NN is N - 1, sum(NN, SS), S is N*2 + SS. ?- sum(1,2). yes ?- sum(2,4). no ?- sum(20,S). S = 420 Logic Languages Problem: sum twice the numbers from 1 to N Prolog

25. Advantages of the DSL Approach • Programs in the target domain are: • more concise • quicker to write • easier to maintain • easier to reason about • written by non-programmers Contribute to higher programmer productivity Dominant cost in large SW systems Formal verification, program transformation, compiler optimization These are the same arguments in favor of any high-level language! But in addition, we should add: Helps bridge gap between developer and user 600.325/425 Declarative Methods - J. Eisner slide partly thanks to Tim Sheard

26. Potential Disadvantages of DSL’s • Performance may be poor. • “high-level languages are less efficient” • Unacceptable start-up costs. • design time, implementation, documentation • Tower of Babel. • new language(s) for every domain • Language creep/bloat. • more features added incrementally • Language design/implementation is hard!! • 2-5 years typical for new language 600.325/425 Declarative Methods - J. Eisner slide thanks to Tim Sheard

27. Scripting Languages vs. DSL’s • Scripting languages are DSL’s. • Domain: system components (e.g. GUI widgets, COM/CORBA objects, other programs, etc.). • Examples: Tcl, PERL, Visual Basic, OS shells (such as Unix). • Design/implementation issues are similar. 600.325/425 Declarative Methods - J. Eisner slide thanks to Tim Sheard

28. Embedded Languages • In embedded approach, each domain concept is realized directly as a host-language construct: • domain operators are host-language procedures, • domain types are host-language user-defined data types, etc. • Creating or modifying a DSL is relatively cheap, provided a suitably powerful host language (e.g. Haskell or Lisp) is used. • Embedding may be thought of as rapid prototyping. • Even if the domain ultimately requires generating code for a specialized target environment, the embedded implementation can be used for modeling and simulation. • Many language features needed by a typical DSL • e.g. support for procedural abstraction; modules; etc will already exist in the host language; • It is straightforward to integrate code from multiple DSLs if they share the same host implementation. 600.325/425 Declarative Methods - J. Eisner slide thanks to Tim Sheard

29. Stand-alone System • A stand-alone implementation for a DSL can have its own syntax and type system appropriate for just that domain. • The DSL can be ``restricted" to enforce constraints on what can be expressed. • The DSL can have its own optimizer that relies on domain-specific optimization rules so that performance bottlenecks can be addressed. • Automated construction tools for interpreters and compilers can make building a stand-alone system cheaper; while many such tools exist, some important ones are still missing. 600.325/425 Declarative Methods - J. Eisner slide thanks to Tim Sheard

30. A User centered Approach to Language Design • Languages can be designed around several issues • To solve a computational problem • To make the implementers job easier • To make the programmer’s (user of the language) life easier • Which of these do you think is the most important? • Which of these gets the most attention in the programming language literature? 600.325/425 Declarative Methods - J. Eisner slide thanks to Tim Sheard

31. Sort(X) = permutation of X whose elements are pairwise ordered • divide(6,2) = some number x such that 2*x=6 (Could solve by a general equation solver, or by Prolog) • sqrt(-6) = ... 600.325/425 Declarative Methods - J. Eisner

32. Language Influences Programming Practice • Languages often strongly favor a particular style of programming • Object-oriented languages: a style making heavy use of objects • Functional languages: a style using many small side-effect-free functions • Logic languages: a style using searches in a logically-defined problem space 600.325/425 Declarative Methods - J. Eisner slide thanks to Adam Webber (modified)

33. Fighting the Language • Languages favor a particular style, but do not force the programmer to follow it • It is always possible to write in a style not favored by the language • It is not usually a good idea… 600.325/425 Declarative Methods - J. Eisner slide thanks to Adam Webber (modified)

34. Example: APL Factorial • An APL expression that computes X’s factorial • Expands X it into a vector of the integers 1..X, then multiplies them all together • (You would not really do it that way in APL, since there is a predefined factorial operator: !X) • Could be called functional, but has little in common with most functional languages    X 600.325/425 Declarative Methods - J. Eisner slide thanks to Adam Webber (modified)

35. Programming Experience Influences Language Design • Corrections to design problems make future dialects, as already noted • Programming styles can emerge before there is a language that supports them • Programming with objects predates object-oriented languages • Automated theorem proving predates logic languages 600.325/425 Declarative Methods - J. Eisner slide thanks to Adam Webber (modified)

36. Turing Equivalence • General-purpose languages have different strengths, but fundamentally they all have the same power • {problems solvable in Java}= {problems solvable in Fortran}= … • And all have the same power as various mathematical models of computation • = {problems solvable by Turing machine}= {problems solvable by lambda calculus}= … • Church-Turing thesis: this is what “computability” means 600.325/425 Declarative Methods - J. Eisner slide thanks to Adam Webber (modified)

37. Declarative Programming • A logic program defines a set of relations. This “knowledge” can be used in various ways by the interpreter to solve different queries. • In contrast, the programs in other languages make explicit HOW the “declarative knowledge” is used to solve the query. 600.325/425 Declarative Methods - J. Eisner slide thanks to T.K. Prasad (modified)

38. Imperative vs Non-Imperative • Functional/Logic programs specify WHAT is to be computed abstractly, leaving the details of data organization and instruction sequencing to the interpreter. • In constrast, Imperative programs describe the details of HOW the results are to be obtained, in terms of the underlying machine model. 600.325/425 Declarative Methods - J. Eisner slide thanks to T.K. Prasad (modified)

39. Imperative vs Non-Imperative • Functional/Logic style clearly separates WHAT aspects of a program (programmers’ responsibility) from the HOW aspects (implementation decisions). • An Imperative program contains both the specification and the implementation details, inseparably inter-twined. 600.325/425 Declarative Methods - J. Eisner slide thanks to T.K. Prasad (modified)

40. Program: a sequence of instructions for a von Neumann m/c. Computation by instruction execution. Iteration. Modifiable or updateable variables. Program: a collection of function definitions (m/c independent). Computation by term rewriting. Recursion. Assign-only-once variables. Procedural vs Functional 600.325/425 Declarative Methods - J. Eisner slide thanks to T.K. Prasad (modified)

41. Emphasis on procedural abstraction. Top-down design; Step-wise refinement. Suited for programming in the small. Emphasis on data abstraction. Bottom-up design; Reusable libraries. Suited for programming in the large. Procedural vs Object-Oriented 600.325/425 Declarative Methods - J. Eisner slide thanks to T.K. Prasad (modified)

42. Procedural vs Object-Oriented • New operations cause additive changesin procedural style, but require modifications to all existing “class modules” in object-oriented style. • New data representations cause additive changes in object-oriented style, but require modifications to all “procedure modules”. 600.325/425 Declarative Methods - J. Eisner slide thanks to T.K. Prasad (modified)

43. Further Perspective In addition to labels of functional, procedural, and OO languages, we might also categorize languages based on whether they are interpreted or compiled(or even a hybrid). Interpreted languages are evaluated one step at a time, with values and variables being determined dynamically at run time. Compiled languages are assembled into memory, with address locations and offsets precalculated, and then crafted into an “executable” program. 600.325/425 Declarative Methods - J. Eisner slide thanks to Jim Greenlee (modified)

44. What is a programming language? “…a set of conventions for communicating an algorithm.” - Horowitz Purposes • specifying algorithms and data • communicating to other people • establishing correctness this and following slides thanks to James Montgomery

45. Why use anything other than machine code? • readability • machine independence • program libraries • consistency checking during implementation (e.g., type-checking) • acceptable loss of efficiency • dealing with scale “The art of programming is the art of organising complexity” - Dijkstra

46. Why learn more than one programming language? • language encourages thinking about problem in a particular way • depending on problem, one way of thinking may be better • language should match the problem • many factors govern choice of language • correctness and efficiency of resulting programs • ease of development and maintenance • reusability and interoperability • …

47. History of Programming Languages Prehistory • c2000 BC, Babylon: “Algorithms” for calendar computation, no explicit conditionals or iteration • c300 BC, Greece: Euclid expresses the greatest common divisor algorithm using iteration • c1820-1870, England: Countess Ada Lovelace writes programs for Babbage’s analytic engine • 1950s: first modern programming languages appear

48. History of Programming Languages FORTRAN 1954-1957, John Backus (IBM) • numeric, scientific computing • fixed format for punched cards • implicit typing • only numeric data • only bounded loops, test vs zero Algol 60 1958-1960, International committee • numeric, scientific computing • free format, reserved words • block structure and lexical scope • while loops, recursion • explicit typing • BNF for formal syntax definition

49. History of Programming Languages COBOL 1959-1960, DoD committee • business data processing • explicit data description • records and file handling • English-like syntax APL 1956-1960, Ken Iverson (IBM) • array processing • functional programming style • nonstandard character set • multidimensional arrays Lisp 1956-1962, John McCarthy (Stanford) • symbolic computing: AI • functional programming style • same representation for program and data • garbage collection

50. History of Programming Languages SNOBOL 1962-1966, Farber, et al. (Bells Labs) • string processing • powerful pattern matching PL/I 1963-1964, IBM • general purpose programming • powerful pattern matching • planned successor to FORTRAN, Algol 60, COBOL • user-defined exceptions • multi-tasking Simula67 1967, Dahl & Nygaard • simulation • class concept for data abstraction • persistent objects • inheritance of properties