CS 351 Introduction Mark Hennessy CS 351 Dept

CS 351 Introduction Mark Hennessy CS 351 Dept. Computer Science NUIM

CS 351 Cirriculum l Before: Functional Programming l Logic Programming l Parallel Programming l GUI Programming l Mark Hennessy CS 351 Dept. Computer Science NUIM : Ca. ML : Prolog : C examples : Java Swing

CS 351 l This year: l Functional Programming via Ca. ML l l l Logic Programming via Prolog l l Theorectical Aspects of FP Learn syntax of ML via lab practicals. Threory with lab practicals. Object-Oriented Paradigm via C++ Learn about Inheritence, Polymorphism, Multiple Inheritence and the generic Paradigm via Templates and the STL. ( Possibly some GUI. ) l l Scripting Languages l Bash and Python. Mark Hennessy CS 351 Dept. Computer Science NUIM

Course Objectives l To provide students with : l An understanding of programming paradigms, and the relationship of language type to application areas l Knowledge of representative languages, and experience in using them l Understanding and experience of how to approach programming for the various paradigms Mark Hennessy CS 351 Dept. Computer Science NUIM

Lecture Overview A brief history of Computer Languages l Introducing the Paradigms l l Defining the Paradigms l Declarative l l l Lisp/Scheme, ML, Haskell Prolog Imperative l l l Functional e. g Logic Languages Von Neuman Languages Object-Oriented Fortran, Pascal, Basic, C Smalltalk, C++, Java# Textbook: Programming Language Pragmatics by Michael L. Scott, 2 nd. Ed. Mark Hennessy CS 351 Dept. Computer Science NUIM

Evolution of Programming Languages • FORTRAN ( FORmula TRANslator) Goals : Scientific Computations Efficiency of execution Compile-time storage determination Features : Symbolic Expressions Subprograms Absence of Recursion • COBOL Goal: Business Application Features : Record/Structure; File Handling Mark Hennessy CS 351 Dept. Computer Science NUIM

Evolution of Programming Languages • ALGOL - 60 (ALGOrithmic Language) Goals : Communicating Algorithms Features : Block Structure (Top-down design) Recursion (Problem-solving strategy) BNF - Specification • LISP (LISt Processing) Goals : Manipulating symbolic information Features : List Primitives Interpreters / Environment Mark Hennessy CS 351 Dept. Computer Science NUIM

Evolution of Programming Languages • Pascal Goal : Structured Programming, Type checking, Compiler writing. Features : • Rich set of data types for efficient algorithm design • E. g. , Records, sets, . . . • Variety of “readable” single-entry single-exit control structures • E. g. , for-loop, while-loop, . . . • Efficient Implementation • Recursive descent parsing Mark Hennessy CS 351 Dept. Computer Science NUIM

Evolution of Programming Languages l Object-Oriented Programs: l l l Smalltalk and Ada in the early 1980’s. C++ started in the late 80’s but only standardised in 1998. Java is only about 10 years old. OO Programming removed the need for monolithic programs. l Programs are developed in teams and code sharing and re-use is fundamental to the success of the OO paradigm. l OO places a strong emphasis on correctness, robustness and reliability. l l E. g through Data Abstraction, Encapsulation and Strong Typing Mark Hennessy CS 351 Dept. Computer Science NUIM

What is a paradigm? l 500 BC, articles shown side-by-side on a market-stall so they can be compared l 300 BC, an article used as a sample of goods l 1000 AD, an example of a general class of objects. l 1600 AD, a standard example used in teaching (humanities). Mark Hennessy CS 351 Dept. Computer Science NUIM

Scientific Paradigms l 1700 AD. A standard example used to test a theory or a method. l 1800 AD. A theory or method. l Computer science: A coherent set of methods characterised by a single principle, simple to formulate, that have been found to be effective in handling a given type of problem. Mark Hennessy CS 351 Dept. Computer Science NUIM

Definition of a Paradigm l An archetype for modeling and solving problems. l Inherent are basic assumptions about the nature of problems, l how they are to be approached. l l Paradigms are the way that we think about problems l Fundamental to the study of programming languages Mark Hennessy CS 351 Dept. Computer Science NUIM

Relationship between components of a paradigm

Whats the point of studying paradigms? l valuable for solving problems because: knowing one's paradigm reveals assumptions being made in modeling a problem, which can clarify programming objectives; l being able to state the advantages and drawbacks of various paradigms permits someone to decide between them based on the problem at hand. l Mark Hennessy CS 351 Dept. Computer Science NUIM

Choosing a paradigm l It can be shown that anything solvable using one of these paradigms can be solved using the others l However, certain types of problems lend themselves more naturally to specific paradigms. l Different Programming languages implement differnet paradigms. Mark Hennessy CS 351 Dept. Computer Science NUIM

Assembly Language ADDI R 4, R 2, 21 ADDI R 4 R 2 21 1010110010000000010101 l Use symbols instead of binary digits to describe fields of instructions. l Every aspect of machine visible in program: One statement per machine instruction. l Register allocation, call stack, etc. must be managed explicitly. l l No structure: everything looks the same.

Pros and Cons of Assembly Language l Avoids Absolute Addressing l l relocatable, reusable/shareable Uses Symbolic Names l readable l Low-level programming wastes effort in coding a solution rather than solving a problem. l Difficult to build and maintain large programs. Mark Hennessy CS 351 Dept. Computer Science NUIM

High-level Language l Provides notation to describe problem solving strategies rather than organize data and instructions at machine-level. l Improves programmer productivity by supporting features to abstract/reuse code, and to improve reliability/robustness of programs. l Requires a compiler. Mark Hennessy CS 351 Dept. Computer Science NUIM

Solving Problems via high level languages l Three basic techniques: 1. Decomposition: subdivide the problem l 2. Abstraction: ignore irrelevant detail safely l 3. Contextual checking: independent agent checks for internal consistency l l Structured programming: over-used term for using complexity-reducing techniques (meaningless these days). Mark Hennessy CS 351 Dept. Computer Science NUIM

1) Program Decompositon “Divide and conquer” l “Solving several small problems is easier than solving one large one of the same size” Lead to: l Step-wise refinement l functional decomposition l Modular decomposition l Object-oriented design l Mark Hennessy CS 351 Dept. Computer Science NUIM

1(a) Stepwise Refinement l In each step, one or several instructions of the program are decomposed into more detailed instructions l Terminates when all instructions are expressible in programming language l Data may be refined, decomposed or structured in parallel. l Each step implies a design decision. l Alternative solutions at each step Mark Hennessy CS 351 Dept. Computer Science NUIM

1(b) Modular Design l Uses abstraction and information hiding l Functional independence, measured by: Internal cohesion (does/deals with one thing) l External coupling (interface complexity) l l Makes modification easier l Reduces error propagation l Reusability Mark Hennessy CS 351 Dept. Computer Science NUIM

1(c) Object Oriented Design l Builds upon 3 software design concepts l Abstraction l Information Hiding l Modularity l Provides a mechanism to achieve these without complexity or compromise l System maps to real world rather than vice-versa Mark Hennessy CS 351 Dept. Computer Science NUIM

2) Abstraction l Abstraction = “ignore irrelevant detail in a safe way” l Irrelevant = no concern to user in solving the problem e. g. representation of a date as: a triplet record l an integer (days since 1/1/1900) l l Implies the existence of a user/object interface Mark Hennessy CS 351 Dept. Computer Science NUIM

2(a) Object Interfaces l Includes operations on the data type l Independent of how data is implemented l User can abstract from internal details l Implementer can change nternal details l Interface can be in mind of user Restricts themselves to ‘published’ facilities l Requires disciplined programming l Mark Hennessy CS 351 Dept. Computer Science NUIM

2(b) Abstraction ‘in a safe way’ l User is forced to abstract from detail l Required facilities built-in to language l Package or Module l Encapsulated implementation of a set of services l Achieved through name manipulation l Names of secret objects unknown on user’s side of interface Mark Hennessy CS 351 Dept. Computer Science NUIM

3) Contextual Checking l Only l simple checks possible undeclared ids, # parameters in procedure l Some checks recursively insoluble e. g. termination, overflow l Run-time errors l l Strong type checking l Heuristic checks - necessary but not sufficient l e. g. escape from recursion Mark Hennessy CS 351 Dept. Computer Science NUIM