CS 351 Introduction

skatechildrenSoftware and s/w Development

Nov 3, 2013 (3 years and 7 months ago)

71 views

Mark Hennessy CS351 Dept.
Computer Science NUIM

CS 351 Introduction

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

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.

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


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 Languages


Prolog


Imperative


Von Neuman Languages

Fortran, Pascal, Basic, C


Object
-
Oriented


Smalltalk, C++, Java#


Textbook: Programming Language Pragmatics
by Michael L. Scott, 2
nd
. Ed.

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

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

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

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

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).


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.


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


Relationship between
components of a paradigm

Sorting words alphabetically
impementation
methods
concepts
Principle: the fully specified and fully controlled manipulation of named data in a step-wise
fashion.
PARADIGM = principle + concepts + methods.
Allocatable data
(records)
reference to data
(pointers)
repetition
(while loop)
linked
lists
external data
(files)
input
output
Program
(sorter)
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.


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.

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.


101011
00100
00010
0000000000010101

ADDI

R4

R2

21

ADDI R4,R2,21

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.

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
.

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).


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

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

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

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


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


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

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


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