Programming paradigm: Difference between revisions
m rm link to deleted article |
Seizethedave (talk | contribs) m links |
||
Line 2: | Line 2: | ||
A '''programming paradigm''' is a fundamental style of [[computer programming]]. (Compare with a [[methodology (software engineering)|methodology]], which is a style of solving specific [[software engineering]] problems). |
A '''programming paradigm''' is a fundamental style of [[computer programming]]. (Compare with a [[methodology (software engineering)|methodology]], which is a style of solving specific [[software engineering]] problems). |
||
A programming language can support [[Multi-paradigm programming language|multiple paradigms]]. For example programs written in C++ or Object Pascal can be purely [[procedural programming|procedural]], or purely [[object-oriented programming|object-oriented]], or contain elements of both paradigms. |
A [[programming language]] can support [[Multi-paradigm programming language|multiple paradigms]]. For example programs written in [[C++]] or [[Object Pascal]] can be purely [[procedural programming|procedural]], or purely [[object-oriented programming|object-oriented]], or contain elements of both paradigms. Software designers and programmers decide how to use those paradigm elements. |
||
In object-oriented programming, programmers can think of a program as a collection of interacting objects, while in [[functional programming]] a program can be thought of as a sequence of stateless function evaluations. When programming computers or systems with many processors, [[process |
In [[object-oriented programming]], programmers can think of a program as a collection of interacting objects, while in [[functional programming]] a program can be thought of as a sequence of stateless function evaluations. When programming computers or systems with many processors, [[process-oriented programming]] allows programmers to think about applications as sets of concurrent processes acting upon logically shared [[data structures]]. |
||
Just as different groups in [[software engineering]] advocate different ''methodologies'', different [[programming languages]] advocate different ''programming paradigms''. Some languages are designed to support one particular paradigm ([[Smalltalk]] supports object-oriented programming, [[Haskell (programming language)|Haskell]] supports functional programming), while other programming languages support multiple paradigms (such as [[Object Pascal]], [[C++]], [[C Sharp (programming language)|C#]], [[Visual Basic|Visual Basic]], [[Common Lisp]], [[Scheme (programming language)|Scheme]], [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]] and [[Oz programming language|Oz]]). |
Just as different groups in [[software engineering]] advocate different ''methodologies'', different [[programming languages]] advocate different ''programming paradigms''. Some languages are designed to support one particular paradigm ([[Smalltalk]] supports object-oriented programming, [[Haskell (programming language)|Haskell]] supports functional programming), while other programming languages support multiple paradigms (such as [[Object Pascal]], [[C++]], [[C Sharp (programming language)|C#]], [[Visual Basic|Visual Basic]], [[Common Lisp]], [[Scheme (programming language)|Scheme]], [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]] and [[Oz programming language|Oz]]). |
||
Many programming paradigms are as well known for what techniques they ''forbid'' as for what they enable. For instance, pure functional programming disallows the use of [[Side-effect_(computer_science)|side-effects]]; [[structured programming]] disallows the use of [[GOTO|goto]]. Partly for this reason, new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to earlier styles. {{Fact|date=January 2008}} Avoiding certain techniques can make it easier to prove theorems about a program's correctness—or simply to understand its behavior. |
Many programming paradigms are as well known for what techniques they ''forbid'' as for what they enable. For instance, pure functional programming disallows the use of [[Side-effect_(computer_science)|side-effects]]; [[structured programming]] disallows the use of the [[GOTO|goto]] statement. Partly for this reason, new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to earlier styles. {{Fact|date=January 2008}} Avoiding certain techniques can make it easier to prove theorems about a program's correctness—or simply to understand its behavior. |
||
== Examples == |
== Examples == |
Revision as of 02:04, 28 April 2008
A programming paradigm is a fundamental style of computer programming. (Compare with a methodology, which is a style of solving specific software engineering problems).
A programming language can support multiple paradigms. For example programs written in C++ or Object Pascal can be purely procedural, or purely object-oriented, or contain elements of both paradigms. Software designers and programmers decide how to use those paradigm elements.
In object-oriented programming, programmers can think of a program as a collection of interacting objects, while in functional programming a program can be thought of as a sequence of stateless function evaluations. When programming computers or systems with many processors, process-oriented programming allows programmers to think about applications as sets of concurrent processes acting upon logically shared data structures.
Just as different groups in software engineering advocate different methodologies, different programming languages advocate different programming paradigms. Some languages are designed to support one particular paradigm (Smalltalk supports object-oriented programming, Haskell supports functional programming), while other programming languages support multiple paradigms (such as Object Pascal, C++, C#, Visual Basic, Common Lisp, Scheme, Python, Ruby and Oz).
Many programming paradigms are as well known for what techniques they forbid as for what they enable. For instance, pure functional programming disallows the use of side-effects; structured programming disallows the use of the goto statement. Partly for this reason, new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to earlier styles. [citation needed] Avoiding certain techniques can make it easier to prove theorems about a program's correctness—or simply to understand its behavior.
Examples
- Annotative programming (as in Flare language)
- Aspect-oriented programming (as in AspectJ)
- Attribute-Oriented Programming (as in Java 5 Annotations, pre-processed by the XDoclet class; C# Attributes)
- Automata-Based Programming
- Bayesian programming
- Class-based programming, compared to Prototype-based programming (within the context of object-oriented programming)
- Component-oriented programming (as in OLE)
- Concatenative programming
- Constraint programming, compared to logic programming
- Context-oriented programming (as in ContextJ/ContextS/ContextL)
- Cybernetics Oriented Programming
- Dataflow programming (as in spreadsheets)
- Declarative programming
- Flow-based programming
- Function-level programming
- Functional programming
- Goal-directed programming as in Snobol, somewhat similar to Logic Programming
- Imperative programming, compared to declarative programming
- Intentional programming
- Literate Programming
- Logic programming (as in Prolog) and Abductive Logic Programming
- Message passing programming, compared to imperative programming
- Nondeterministic programming
- Object-oriented programming (as in Smalltalk)
- Pipeline programming (as in the UNIX command line)
- Policy-based programming
- Procedural programming, compared to functional programming
- Process-oriented programming a parallel programming model.
- Reactive programming
- Recursive programming, compared to iterative programming
- Reflective programming
- Scalar programming, compared to Array programming
- Structured programming, compared to unstructured programming
- Subject-oriented programming
- Tree programming
- Value-level programming, compared to function-level programming
- Metaprogramming