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

2. Mark Hennessy CS351 Dept. Computer Science NUIM CS 351 Cirriculum Before: Functional Programming : CaML Logic Programming : Prolog Parallel Programming: C examples GUI Programming: Java Swing

3. Mark Hennessy CS351 Dept. Computer Science NUIM CS 351 This year: Functional Programming via CaML Theorectical Aspects of FP Learn syntax of ML via lab practicals. Logic Programming via Prolog 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.) Scripting Languages Bash and Python.

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

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

6. Mark Hennessy CS351 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

7. Mark Hennessy CS351 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

8. Mark Hennessy CS351 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

9. Mark Hennessy CS351 Dept. Computer Science NUIM Evolution of Programming Languages Object-Oriented Programs: 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. Programs are developed in teams and code sharing and re-use is fundamental to the success of the OO paradigm. OO places a strong emphasis on correctness, robustness and reliability. E.g through Data Abstraction, Encapsulation and Strong Typing

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

11. Mark Hennessy CS351 Dept. Computer Science NUIM Scientific Paradigms 1700AD. A standard example used to test a theory or a method. 1800AD. A theory or method. 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.

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

13. Relationship between components of a paradigm

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

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

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

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

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

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

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

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

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

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

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

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

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

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