74199

Programming paradigms

Лекция

Информатика, кибернетика и программирование

Progrmming prdigms. The word progrmming prdigm is used in severl different lthough relted menings in computer science. Progrmming prdigm pttern tht serves s school of thoughts for progrmming of computers. Progrmming technique relted to n lgorithmic ide for solving prticulr clss of problems.

Английский

2014-12-29

45 KB

0 чел.

Lecture 3. Programming paradigms1.

The word programming paradigm is used in several different, although related meanings in computer science.

Programming paradigm – a pattern that serves as a school of thoughts for programming of computers.

Programming technique – related to an algorithmic idea for solving a particular class of problems.

Programming style – the way we express ourselves in a computer program. Related to elegance or lack of elegance

Programming culture – the totality of programming behavior, which often is tightly related to a family of programming languages. The sum of a main paradigm, programming styles, and certain programming techniques.

There are four main programming paradigms and a number of minor programming paradigms.

Main programming paradigms:

  •  The imperative paradigm
  •  The functional paradigm
  •  The logical paradigm
  •  The object-oriented paradigm

Other possible programming paradigms:

  •  The visual paradigm
  •  One of the parallel paradigms
  •  The constraint based paradigm

3.1 Overview of the imperative paradigm.

The word “imperative” can be used both as an adjective and as a noun. As an adjective it means 'expressing a command or plea'. In other words, asking for something to be done. As a noun, an imperative is a command or an order.

Characteristics of the imperative paradigm:

  •  Discipline and idea
    •  Digital hardware technology and the ideas of Von Neumann
    •  Incremental change of the program state as a function of time.
    •  Execution of computational steps in an order governed by control structures
      •  We call the steps for commands
    •  Straightforward abstractions of the way a traditional Von Neumann computer works
    •  Similar to descriptions of everyday routines, such as food recipes and car repair
    •  Typical commands offered by imperative languages
      •  Assignment, IO, procedure calls
    •  Language representatives
      •  Fortran, Algol, Pascal, Basic, C
    •  The natural abstraction is the procedure
      •  Abstracts one or more actions to a procedure, which can be called as a single command.
      •  Procedural programming

Several names are used for the computational steps in an imperative language. The word statement is often used with the special computer science meaning “an elementary instruction in a source language”. The word instruction is another possibility. This word is preferably devoted to the computational steps performed at the machine level. The word “command” is used for the imperatives in a high level imperative programming language.

A procedure abstracts one or more actions to a procedure, which can be activated as a single action.

3.2 Overview of the functional paradigm

Evaluate an expression and use the resulting value for something.

Characteristics of the functional paradigm:

  •  Discipline and idea
    •  Mathematics and the theory of functions
    •  The values produced are non-mutable
      •  Impossible to change any constituent of a composite value
      •  As a remedy, it is possible to make a revised copy of composite value
    •  Atemporal
      •  Time only plays a minor role compared to the imperative paradigm
    •  Applicative
      •  All computations are done by applying (calling) functions
    •  The natural abstraction is the function
      •  Abstracts a single expression to a function which can be evaluated as an expression
    •  Functions are first class values
      •  Functions are full-fledged data just like numbers, lists, ...
    •  Fits well with computations driven by needs
      •  Opens a new world of possibilities

3.3 Overview of the logic paradigm

Answer a question via search for a solution.

Characteristics of the logic paradigm:

  •  Discipline and idea
    •  Automatic proofs within artificial intelligence
    •  Based on axioms, inference rules, and queries.
    •  Program execution becomes a systematic search in a set of facts, making use of a set of inference rules

3.4 Overview of the object-oriented paradigm

Send messages between objects to simulate the temporal evolution of a set of real world phenomena.

Characteristics of the object-oriented paradigm:

  •  Discipline and idea
    •  The theory of concepts, and models of human interaction with real world phenomena
    •  Data as well as operations are encapsulated in objects
    •  Information hiding is used to protect internal properties of an object
    •  Objects interact by means of message passing
      •  A metaphor for applying an operation on an object
    •  In most object-oriented languages objects are grouped in classes
      •  Objects in classes are similar enough to allow programming of the classes, as opposed to programming of the individual objects
      •  Classes represent concepts whereas objects represent phenomena
    •  Classes are organized in inheritance hierarchies
      •  Provides for class extension or specialization

3.5 The visual paradigm

The visual paradigm or visual programming is writing programs in a language which manipulates visual information or supports visual interaction. Visual programming could be:

  •  writing programs in a visual programming language, or
  •  writing programs in a visual programming environment.

Visual programming language (VPL). Any programming language that allows the user to specify a program in a two(or more)-dimensional way. Conventional textual languages are not considered two-dimensional since the compiler or interpreter processes them as one-dimensional streams of characters. A VPL allows programming with visual expressions - spatial arrangements of textual and graphical symbols.

VPLs may be further classified, according to the type and extent of visual expression used, into icon-based languages, form-based languages and diagram languages. Visual programming environments provide graphical or iconic elements which can be manipulated by the user in an interactive way according to some specific spatial grammar for program construction.

A visually transformed language is a non-visual language with a superimposed visual representation. Naturally visual languages have an inherent visual expression for which there is no obvious textual equivalent.

Visual Basic, Visual C++ and the entire Microsoft Visual family are not, despite their names, visual programming languages. They are textual languages which use a graphical GUI builder to make programming interfaces easier. The user interface portion of the programming environment is visual, the languages are not. Because of the confusion caused by the multiple meanings of the term “visual programming”, the term “executable graphics” has been proposed as an alternative to VPL.

Some examples of visual programming languages are Prograph, Pict, Tinkertoy, Fabrik, CODE 2.0 and Hyperpascal.

Visual programming environment. Software which allows the use of visual expressions (such as graphics, drawings, animation or icons) in the process of programming. These visual expressions may be used as graphical interfaces for textual programming languages. They may be used to form the syntax of new visual programming languages leading to new paradigms such as programming by demonstration or they may be used in graphical presentations of the behaviour or structure of a program.

3.6 Common parallel programming paradigms2

Parallel computing using a system such as parallel virtual machine (PVM) may be approached from three fundamental viewpoints, based on the organization of the computing tasks. Within each, different workload allocation strategies are possible.

The first and most common model for PVM applications can be termed “crowd” computing: a collection of closely related processes, typically executing the same code, perform computations on different portions of the workload, usually involving the periodic exchange of intermediate results. This paradigm can be further subdivided into two categories:

The master-slave (or host-node) model in which a separate “control” program termed the master is responsible for process spawning, initialization, collection and display of results, and perhaps timing of functions. The slave programs perform the actual computation involved; they either are allocated their workloads by the master (statically or dynamically) or perform the allocations themselves.

The node-only model where multiple instances of a single program execute, with one process (typically the one initiated manually) taking over the noncomputational responsibilities in addition to contributing to the computation itself.

The second model supported by PVM is termed a “tree”' computation. In this scenario, processes are spawned (usually dynamically as the computation progresses) in a tree-like manner, thereby establishing a tree-like, parent-child relationship (as opposed to crowd computations where a star-like relationship exists). This paradigm, although less commonly used, is an extremely natural fit to applications where the total workload is not known a priori, for example, in branch-and-bound algorithms, alpha-beta search, and recursive “divide-and-conquer”' algorithms.

The third model, termed “hybrid”, can be thought of as a combination of the tree model and crowd model. Essentially, this paradigm possesses an arbitrary spawning structure: that is, at any point during application execution, the process relationship structure may resemble an arbitrary and changing graph.

These three classifications are made on the basis of process relationships, though they frequently also correspond to communication topologies. Nevertheless, in all three, it is possible for any process to interact and synchronize with any other. Further, the choice of model is application dependent and should be selected to best match the natural structure of the parallelized program

3.7 The constraint based paradigm

In computer science, constraint programming is a programming paradigm wherein relations between variables are stated in the form of constraints. Constraints differ from the common primitives of imperative programming languages in that they do not specify a step or sequence of steps to execute, but rather the properties of a solution to be found. This makes constraint programming a form of declarative programming. The constraints used in constraint programming are of various kinds: those used in constraint satisfaction problems (e.g. “A or B is true”), those solved by the simplex algorithm (e.g. “x ≤ 5”), and others. Constraints are usually embedded within a programming language or provided via separate software libraries.

Constraint programming can be expressed in the form of constraint logic programming, which embeds constraints into a logic program. This variant of logic programming is due to Jaffar and Lassez, who extended in 1987 a specific class of constraints that were introduced in Prolog II. The first implementations of constraint logic programming were Prolog III, CLP(R), and CHIP.

Instead of logic programming, constraints can be mixed with functional programming, term rewriting, and imperative languages. Programming languages with built-in support for constraints include Oz (functional programming) and Kaleidoscope (imperative programming). Mostly, constraints are implemented in imperative languages via constraint solving toolkits, which are separate libraries for an existing imperative language.

The constraints used in constraint programming are typically over some specific domains. Some popular domains for constraint programming are:

  •  boolean domains, where only true/false constraints apply (SAT problem)
  •  integer domains, rational domains
  •  linear domains, where only linear functions are described and analyzed (although approaches to non-linear problems do exist)
  •  finite domains, where constraints are defined over finite sets
  •  mixed domains, involving two or more of the above

Finite domains is one of the most successful domains of constraint programming. In some areas (like operations research) constraint programming is often identified with constraint programming over finite domains.

1 http://people.cs.aau.dk/~normark/prog3-03/html/notes/paradigms-book.html

2 http://www.netlib.org/pvm3/book/node28.html


 

А также другие работы, которые могут Вас заинтересовать

14718. Визначення втрат тепла з відпрацьованими газами двигуна внутрішнього згоряння 135.5 KB
  Лабораторна робота №5 Визначення втрат тепла з відпрацьованими газами двигуна внутрішнього згоряння Мета роботи: експериментальне визначення витрат тепла поршневого двигуна внутрішнього згоряння з відпрацьованими газами на різних режимах його роботи. Обладн
14719. Вплив регулювань системи запалювання на потужнісні характеристики автомобільного двигуна 356 KB
  Лабораторна робота №2 Вплив регулювань системи запалювання на потужнісні характеристики автомобільного двигуна Мета роботи: визначення впливу регулювань системи запалювання автомобільного двигуна на показники його потужності і приймістості. Обладнання: дви...
14720. Визначення втрат тепла через систему охолодження автомобільного двигуна 405.5 KB
  Лабораторна робота № 4 Визначення втрат тепла через систему охолодження автомобільного двигуна Мета роботи: Вивчення теплового балансу двигуна і практичне визначення втрат тепла через систему охолодження автомобільного двигуна. Обладнання: Двигун ЗІЛ 130 ...
14721. Алгоритм анализа качества системы при детерминированных и случайных воздействиях 80.51 KB
  Алгоритм анализа качества системы при детерминированных и случайных воздействиях Задача анализу известной динамической системы в конкретных условиях ее эксплуатации состоит в определении выходных реакций и сигналов управления систем при определенных входных сигнал...
14722. Таблицы решений 128 KB
  Лабораторная работа № 3. Таблицы решений Цель работы Целью работы является изучение таблиц решений и спецификация с помощью данного механизма логики вычислительных процессов. Содержание отчета Итоговым документом выполнения лабораторной работы является отчет с
14723. Flow-формы и диаграммы Насси-Шнейдермана 44 KB
  Лабораторная работа № 2. Flowформы и диаграммы НассиШнейдермана Цель работы Изучение и практическое применение принципов разработки спецификаций вычислительных процессов с помощью визуальных языков Flowформ и диаграмм НассиШнейдермана. Содержание отчета Итоговы
14724. Схемы алгоритмов 76 KB
  Контрольная работа. Схемы алгоритмов Цель работы Целью работы является практическое изучение процесса спецификации алгоритмов с помощью схем. Содержание отчета Итоговым документом выполнения контрольной работы является отчет состоящий из следующих пунктов. ...
14725. Определение ускорения свободного падения с помощью оборотного маятника 48 KB
  отчёт по лабораторной работе № 20 Определение ускорения свободного падения с помощью оборотного маятника Расчетная формула. 4πL₀ T где L₀ приведенная длина оборотного маятника; T период колебаний маятника. Эскиз установки. ...
14726. Анализ дискретной математической модели непрерывного динамического объекта 463.34 KB
  Лабораторная работа №4 Анализ дискретной математической модели непрерывного динамического объекта Цели работы: выполнить анализ заданного непрерывного объекта; выбрать несколько периодов квантования объекта; получить дискретные ММ непрерывного объект