1 / 27

CS 351 Introduction

CS 351 Introduction. CS 351 Cirriculum. Before: Functional Programming : CaML Logic Programming : Prolog Parallel Programming : C examples GUI Programming : Java Swing. CS 351. This year: Functional Programming via CaML Theorectical Aspects of FP

kilenya-young
Download Presentation

CS 351 Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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. Mark Hennessy CS351 Dept. Computer Science NUIM

  4. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

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

  6. 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 CS351 Dept. Computer Science NUIM

  7. 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 CS351 Dept. Computer Science NUIM

  8. 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 CS351 Dept. Computer Science NUIM

  9. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  10. 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). Mark Hennessy CS351 Dept. Computer Science NUIM

  11. 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. Mark Hennessy CS351 Dept. Computer Science NUIM

  12. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  13. Relationship between components of a paradigm

  14. 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. Mark Hennessy CS351 Dept. Computer Science NUIM

  15. 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. Mark Hennessy CS351 Dept. Computer Science NUIM

  16. Assembly Language ADDI R4 R2 21 ADDI R4,R2,21 10101100100000100000000000010101 • 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.

  17. 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. Mark Hennessy CS351 Dept. Computer Science NUIM

  18. 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. Mark Hennessy CS351 Dept. Computer Science NUIM

  19. 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). Mark Hennessy CS351 Dept. Computer Science NUIM

  20. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  21. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  22. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  23. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  24. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  25. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  26. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

  27. 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 Mark Hennessy CS351 Dept. Computer Science NUIM

More Related