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
0cb a
6e0c
06b
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/ but most “proper” programming still done in assembly language.

7. Reducing machine dependency – portability.
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 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. Imperative Languages Problem: sum twice the numbers from 1 to N
DO 11 K = 1, N
SUM = SUM + 2 * K
11 CONTINUE
FORTRAN
sum = 0;
for (k=1; k<=N; k++)
sum += 2*k; C
sum := 0;
for j :=1 to N do
sum := sum + 2*k;
Algol

22. Object-oriented Languages
Problem: sum twice the numbers from 1 to N
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; }
C++

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

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

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
/425 Declarative Methods - J. Eisner
slide partly thanks to Tim Sheard 8

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
/425 Declarative Methods - J. Eisner
slide thanks to Tim Sheard 10

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.
/425 Declarative Methods - J. Eisner
slide thanks to Tim Sheard 6

28. 600.325/425 Declarative Methods - J. Eisner
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.
/425 Declarative Methods - J. Eisner
slide thanks to Tim Sheard

29. 600.325/425 Declarative Methods - J. Eisner
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.
/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?
/425 Declarative Methods - J. Eisner
slide thanks to Tim Sheard

31. 600.325/425 Declarative Methods - J. Eisner
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) = ...
/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
/425 Declarative Methods - J. Eisner
slide thanks to Adam Webber (modified)

33. 600.325/425 Declarative Methods - J. Eisner
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…
/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
/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
/425 Declarative Methods - J. Eisner
slide thanks to Adam Webber (modified)

36. 600.325/425 Declarative Methods - J. Eisner
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
/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.
/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.
/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.
/425 Declarative Methods - J. Eisner
slide thanks to T.K. Prasad (modified)

40. Procedural vs Functional
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.
/425 Declarative Methods - J. Eisner
slide thanks to T.K. Prasad (modified)

41. Procedural vs Object-Oriented
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.
/425 Declarative Methods - J. Eisner
slide thanks to T.K. Prasad (modified)

42. Procedural vs Object-Oriented
New operations cause additive changes in 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”.
/425 Declarative Methods - J. Eisner
slide thanks to T.K. Prasad (modified)

43. 600.325/425 Declarative Methods - J. Eisner
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.
/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
c , England: Countess Ada Lovelace writes programs for Babbage’s analytic engine
1950s: first modern programming languages appear

48. History of Programming Languages
FORTRAN , John Backus (IBM)
numeric, scientific computing
fixed format for punched cards
implicit typing
only numeric data
only bounded loops, test vs zero
Algol , International committee
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 , DoD committee
business data processing
explicit data description
records and file handling
English-like syntax
APL , Ken Iverson (IBM)
array processing
functional programming style
nonstandard character set
multidimensional arrays
Lisp , John McCarthy (Stanford)
symbolic computing: AI
same representation for program and data
garbage collection

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

51. History of Programming Languages
Algol
general purpose programming
orthogonal language design
powerful mechanism for type definition
formal operational semantics
Pascal 1969, Wirth
teaching language
1 pass compiler
call-by-value semantics
Prolog 1972, Colmerauer & Kowalski
AI applications
logic programming
theorem proving based on unification

52. History of Programming Languages
C 1974, Ritchie (Bell Labs)
systems programming
access to machine level
efficient code generation
CLU , Liskov (MIT)
simulation
data abstraction and exceptions
operational semantics
attempt to enable program verification
Smalltalk mid 1970s, Kay (Xerox PARC)
rapid prototyping
strictly object-oriented: encapsulation and inheritance
easy to write programs with complex behaviour

53. History of Programming Languages
Modula 1977, Wirth
general purpose programming
modules to control interfaces between sets of procedures
real-time programming
targets large software development
Ada 1977, DoD committee
explicit parallelism: rendezvous
exception handling
Concurrent Pascal 1976, Brinch-Hansen
asynchronous concurrent processes
monitors for safe data sharing

54. History of Programming Languages
Scheme , Sussman and Steele
general-purpose programming
slimline and uniform Lisp
closer to the Lambda Calculus
ML 1978, Milner
powerful type-checking
advanced garbage-collection

55. History of Programming Languages
C , Stroustrop (Bell Labs)
general purpose programming
goal: type-safe object-oriented programming
templates allow limited higher-order programming
Java Arnold, Gosling, and Steele (Sun)
type-safe object-oriented programming
platform independent (designed for web programming)
exception handling
threads
Haskell , Edinburgh and Yale
general-purpose programming
powerful functional language

56. PROGRAMMING PARADIGMS?
In science a paradigm describes a set of techniques that have been found to be effective for a given problem domain (i.e somebody somewhere must believe in it).
A paradigm can typically be expressed in terms of a single principle (even if this is in fact an over simplification).
This principle must be supported by a set of techniques.
In the context of programming languages we say that a paradigm induces a particular way of thinking about the programming task.

57. We can identify four principal programming paradigms:
Imperative (e.g. Pascal, Ada, C).
Object-oriented (e.g. Java).
Functional (e.g. Haskell, SML).
Logic (e.g. Prolog).

58. PROGRAMMING MODELS
The 4 main programming paradigms aim at solving general programming problems, but sometimes there are additional aspects to a problem which require us to “tweak” a paradigm.
The result is not a new paradigm but a programming model founded on a particular paradigm.
An example is parallel or distributed programming.

59. SUMMARY Classification of languages: Machine, assembler & high level
Chronological order
Generations
Levels of abstraction
Declarative v Non-declarative.
Paradigms
Programming models