Programming paradigm

From Wikipedia, the free encyclopedia

Jump to: navigation, search

A programming paradigm is a fundamental style of computer programming. (Compare with a methodology, which is a style of solving specific software engineering problems). Paradigms differ in the concepts and abstractions used to represent the elements of a program (such as objects, functions, variables, constraints, etc.) and the steps that compose a computation (assignation, evaluation, continuations, data flows, etc.).


[edit] Overview

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, Perl,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.[1] Avoiding certain techniques can make it easier to prove theorems about a program's correctness—or simply to understand its behavior.

[edit] History

Initially, computers were hard-wired or 'soft-wired' (see IBM 805 Test Scoring Machine) and then later programmed using binary code that represented control sequences fed to the computer CPU. This was difficult and error-prone. Programs written in binary are said to be written in machine code, which is a very low-level programming paradigm.

To make programming easier, assembly languages were developed. These replaced machine code functions with mnemonics and absolute memory addresses with symbolic labels. Assembly language programming is considered a low-level paradigm although it is a 'second generation' paradigm. Even 1960's assembly languages actually supported library COPY and quite sophisticated conditional macro generation and pre-processsing capabilities. They also supported modular programming features such as CALL, external variables and common sections (globals), enabling significant code re-use. Although a significant improvement over machine code, it is claimed that assembler it is still more prone to errors , difficult to debug and maintain[dubious ] than alternative languages/paradigms (Despite this, continual development of assembler continues, as mentioned later, in discussion of the object-oriented paradigm)

The next advance was the development of procedural languages. These third-generation languages (the first described as high-level languages) use vocabulary related to the problem being solved. For example,

were developed mainly for commercial or scientific and engineering problems, although one of the ideas behind the development of ALGOL was that it was an appropriate language to define algorithms.

  • PL/1 (Programming language 1) - a hybrid commercial/scientific general purpose language supporting pointers
  • BASIC (Beginners All purpose Symbolic Instruction Code) - was developed to enable more people to

write programs.

All these languages follow the procedural paradigm. That is, they describe, step by step, exactly the procedure that should be followed to solve a problem - familiar to most people from other disciplines. These new languages did not replace assembler and were deleloped more or less in parallel. Assembler was, and still is, used for time critical systems and frequently in embedded systems.

It is claimed by some that the problem with procedural languages is that it can be difficult to reuse code[dubious ]and to modify solutions[dubious ] when better methods of solution are developed[dubious ].

In order to address these perceived problems, object-oriented languages (like Eiffel, Smalltalk and Java) were developed. In these languages data, and methods of manipulating the data, are kept as a single unit called an object. The only way that a user can access the data is via the object's 'methods' (subroutines). This means that, once an object is fully working, it cannot be corrupted by the user[dubious ]. It also means that the internal workings of an object may be changed without affecting any code that uses the object.

Since object-oriented programming is a paradigm, not a language, it is possible to create even an object-oriented assembler language. High Level Assembly (HLA) is an example of this that fully supports advanced data types and object-oriented assembly language programming..

A further advance was made when declarative programming paradigms were developed. In these languages the computer is told what the problem is, not how to solve the problem - the program is structured as a collection of properties to find in the expected result, not as a procedure to follow. Given a database or a set of rules, the computer tries to find a solution matching all the desired properties. The archetypical example of a declarative language is the fourth generation language SQL, as well as the family of functional languages.

Functional programming is a subset of declarative programming. Programs written using this paradigm use functions, blocks of code intended to behave like mathematical functions. Functional languages discourage changes in the value of variables through assignment, making a great deal of use of recursion instead.

[edit] See also

[edit] References

  1. ^ Frank Rubin published a criticism of Dijkstra's letter in the March 1987 CACM where it appeared under the title 'GOTO Considered Harmful' Considered Harmful. Frank Rubin (March 1987). ""GOTO Considered Harmful" Considered Harmful" (PDF). Communications of the ACM 30 (3): 195–196. doi:10.1145/214748.315722. 

[edit] External links

Personal tools