Editing Programming paradigm (section)

== Overview ==
[[File:Programming paradigms.svg|thumb|250px|left|Overview of the various programming paradigms according to Peter Van Roy<ref>{{Cite web
 |url= http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
 |title= Programming Paradigms: What Every Programmer Should Know
 |date= 2009-05-12 |access-date= 2014-01-27
 |author= Peter Van Roy |publisher= info.ucl.ac.be
 }}</ref>{{rp|5}}<ref name="Van-RoyHaridi2004">{{cite book|author1=Peter Van-Roy|author2=Seif Haridi|title=Concepts, Techniques, and Models of Computer Programming|url=https://books.google.com/books?id=_bmyEnUnfTsC|year=2004|publisher=MIT Press|isbn=978-0-262-22069-9}}</ref>]]

Programming paradigms come from [[computer science]] [[research]] into existing practices of [[software development]]. The findings allow for describing and comparing programming practices and the languages used to code programs. For perspective, other fields of research study 
[[software engineering]] [[process]]es and describe various [[Methodology|methodologies]] to describe and compare them.

A [[programming language]] can be described in terms of paradigms. Some languages support only one paradigm. For example, [[Smalltalk]] supports object-oriented and [[Haskell]] supports functional. Most languages support multiple paradigms. For example, a program written in [[C++]], [[Object Pascal]], or [[PHP]] can be purely [[Procedural programming|procedural]], purely [[Object-oriented programming|object-oriented]], or can contain aspects of both paradigms, or others. 

When using a language that supports multiple paradigms, the developer chooses which paradigm elements to use. But, this choice may not involve considering paradigms per se. The developer often uses the features of a language as the language provides them and to the extent that the developer knows them. Categorizing the resulting [[Source code|code]] by paradigm is often an academic activity done in retrospect.

Languages categorized as '''imperative paradigm''' have two main features: they state the order in which operations occur, with constructs that explicitly control that order, and they allow side effects, in which state can be modified at one point in time, within one unit of code, and then later read at a different point in time inside a different unit of code.  The communication between the units of code is not explicit.

In contrast, languages in the '''declarative paradigm''' do not state the order in which to execute operations. Instead, they supply a number of available operations in the system, along with the conditions under which each is allowed to execute.<ref>{{Cite web |title=Programming paradigms: What are the principles of programming? |url=https://www.ionos.com/digitalguide/websites/web-development/programming-paradigms/ |url-status=live |access-date=2022-05-03 |website=IONOS Digitalguide |date=20 April 2020 |language=en-US |archive-url=https://web.archive.org/web/20220629200645/https://www.ionos.com/digitalguide/websites/web-development/programming-paradigms/ |archive-date=Jun 29, 2022}}</ref>  The implementation of the language's execution model tracks which operations are free to execute and chooses the order independently. More at  [[Comparison of multi-paradigm programming languages]].

In '''object-oriented''' programming, code is organized into [[Object (programming)|objects]] that contain state that is owned by and (usually) controlled by the code of the object.  Most object-oriented languages are also imperative languages.

In object-oriented programming, programs are treated as a set of interacting objects. In [[functional programming]], programs are treated as a sequence of stateless function evaluations. When programming computers or systems with many processors, in [[process-oriented programming]], programs are treated as sets of concurrent processes that act on a logical shared [[data structure]]s.

Many programming paradigms are as well known for the techniques they ''forbid'' as for those they ''support''. For instance, pure functional programming disallows [[side-effect (computer science)|side-effects]], while [[structured programming]] disallows the [[goto]] construct. Partly for this reason, new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to older ones.<ref name="rubin87goto">{{cite journal|author=Frank Rubin |date=March 1987 |url=http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf |title='GOTO Considered Harmful' Considered Harmful |journal=Communications of the ACM |volume=30 |issue=3 |pages=195–196 |doi=10.1145/214748.315722 |s2cid=6853038 |url-status = dead|archive-url=https://web.archive.org/web/20090320002214/http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf |archive-date=March 20, 2009}}</ref> Yet, avoiding certain techniques can make it easier to understand program behavior, and to [[Automated theorem proving|prove theorems]] about program correctness.

Programming paradigms can also be compared with ''[[programming model]]s'', which allows invoking an [[execution model]] by using only an API. Programming models can also be classified into paradigms based on features of the execution model.

For [[parallel computing]], using a programming model instead of a language is common.  The reason is that details of the parallel hardware leak into the abstractions used to program the hardware.  This causes the programmer to have to map patterns in the algorithm onto patterns in the execution model (which have been inserted due to leakage of hardware into the abstraction).  As a consequence, no one parallel programming language maps well to all computation problems.  Thus, it is more convenient to use a base sequential language and insert API calls to parallel execution models via a programming model.  Such parallel programming models can be classified according to abstractions that reflect the hardware, such as [[shared memory]], [[distributed memory]] with [[message passing]], notions of ''place'' visible in the code, and so forth.  These can be considered flavors of programming paradigm that apply to only parallel languages and programming models.