Comparison of programming paradigms

Comparison of programming paradigms

This article attempts to set out the various similarities and differences between the various programming paradigms as a summary in both graphical and tabular format with links to the separate discussions concerning these similarities and differences in existing Wikipedia articles


Main paradigm approaches

The following are considered[by whom?] the main programming paradigms. There is inevitably some overlap in these non mutually-exclusive paradigms but the main features or identifiable differences are summarized in the following table:

None of the main programming paradigms have a precise, globally unanimous definition, let alone an official international standard. Nor is there any agreement on which paradigm constitutes the best approach to developing software. The subroutines that actually implement OOP methods might be ultimately coded in an imperative, functional or procedural style that might, or might not, directly alter state on behalf of the invoking program.

Paradigm Description Main characteristics (examples) Related paradigm(s) Critics?
Imperative Computation in terms of statements that directly change a program state (datafields) Direct assignments, Common data structures, Global variables Edsger W. Dijkstra, Michael A. Jackson
Structured A style of Imperative programming with more logical program structure Structograms, Indentation, absence of GOTO statements Imperative
Functional Treats computation as the evaluation of mathematical functions avoiding state and mutable data. Lambda calculus, Compositionality, Formula, Referential transparency,

no side effects

Procedural Derived from structured programming, based upon the concept of modular programming or the procedure call Local variables, sequence, selection, iteration, and modularization Structured, Imperative
Event-driven including time driven Program flow is mainly determined by events (such as mouse clicks or interrupts including timer) Main loop, Event handlers, Asynchronous processes Procedural
Object-oriented Treats datafields as "objects" manipulated only through pre-defined methods Objects, Methods, Message passing, Information hiding, Data abstraction, Encapsulation, Polymorphism, Inheritance and Serialization/Marshalling See here and [1][2][3]
Declarative Expresses the logic of a computation without describing its detailed control flow (4GLs, Spreadsheets, Report program generators)
Automata-based programming The program is thought of as a model of a finite state machine or any other formal automata. State enumeration, Control variable, Changes in state, Isomorphism, State transition table Imperative, Event-driven
Paradigm Description Main characteristics (examples) Related paradigm(s) Critics?

Differences in terminology

Despite multiple (types of) programming paradigms existing in parallel (with sometimes apparently conflicting definitions), many of the underlying fundamental components remain more or less the same (constants, variables, datafields, subroutines, Calls etc.) and must somehow therefore inevitably be incorporated into each separate paradigm with equally similar attributes or functions. The table above is not intended as a guide to precise similarities, but more an index of where to look for more information - based on the different naming of these entities - within each paradigm. Non-standardized implementations of each paradigm in numerous programming languages further complicate the overall picture, especially those languages that support multiple paradigms, each with its own jargon.

"You can know the name of a bird in all the languages of the world, but when you're finished, you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's doing-- that's what counts. I learned very early the difference between knowing the name of something and knowing something.

Language support

Syntactic sugar is a term used to describe the "sweetening" of program functionality by the introduction of language features that facilitate particular usage, even if the end result could be achieved without them. One example of syntactic sugar may arguably be classes in C++ (as well as in Java, C#, etc.). The C programming language is fully capable of object-oriented programming using its facilities of function pointers, type casting, and structures. However, languages such as C++ aim to make object-oriented programming more convenient by introducing syntax specific to this coding style. Moreover, the specialized syntax works to emphasize the object-oriented approach. Similarly, functions and looping syntax in C (as well as other procedural and structured programming languages) could be considered syntactic sugar. Assembly language is fully capable of procedural or structured programming using its facilities for modifying register values and branching execution depending on program state. However, languages such as C introduced syntax specific to these coding styles to make procedural and structured programming more convenient. Features of the C# (C Sharp) programming language, such as properties and interfaces, similarly do not enable new functionality, but are designed to make good programming practices more prominent and more natural.

Some programmers feel that these features are either unimportant or outright frivolous. For example, Alan Perlis once quipped, in a reference to bracket-delimited languages, that "syntactic sugar causes cancer of the semicolon" (see Epigrams on Programming).

An extension of this is the term "syntactic saccharin", meaning gratuitous syntax which does not actually make programming easier.[4]

Performance comparison

Purely in terms of total instruction path length, a program coded in an imperative style, without using any subroutines at all, would have the lowest count. However, the binary size of such a program might be larger than the same program coded using subroutines (as in functional and procedural programming) and would reference more "non-local" physical instructions that may increase cache misses and increase instruction fetch overhead in modern processors.

The paradigms that use subroutines extensively (including functional, procedural and object oriented) and do not also use significant inlining (via compiler optimizations) will, consequently, use a greater percentage of total resources on the subroutine linkages themselves. Object oriented programs that do not deliberately alter program state directly, instead using mutator methods (or "setters") to encapsulate these state changes, will, as a direct consequence, have a greater overhead. This is due to the fact that message passing is essentially a subroutine call, but with three more additional overheads: dynamic memory allocation, parameter copying and dynamic dispatch). Obtaining memory from the heap and copying parameters for message passing may involve significant resources that far exceed those required for the state change itself. Accessors (or "getters") that merely return the values of private member variables also depend upon similar message passing subroutines, instead of using a more direct assignment (or comparison), adding to total path length.

Pseudocode examples comparing various paradigms

A pseudocode comparison of imperative, procedural, and object oriented approaches used to calculate the area of a circle (
   \pi r^2.\, ), assuming no subroutine inlining, no macro preprocessors, register arithmetic and weighting each instruction 'step' as just 1 instruction - as a crude measure of instruction path length - is presented below. The instruction step that is conceptually performing the actual state change is highlighted in bold typeface in each case. Note that the actual arithmetic operations used to compute the area of the circle are the same in all three paradigms, with the difference being that the procedural and object-oriented paradigms wrap those operations in a subroutine call that makes the computation general and reusable. The same effect could be achieved in a purely imperative program using a macro preprocessor at just the cost of increased program size (only at each macro invocation site) without a corresponding pro rata runtime cost (proportional to n invocations - that may be situated within an inner loop for instance). Conversely, subroutine inlining by a compiler could reduce procedural programs to something similar in size to the purely imperative code. However, for object-oriented programs, even with inlining, messages still have to be built (from copies of the arguments) for processing by the object oriented methods. The overhead of calls, virtual or otherwise, is not dominated by the control flow alteration itself - but by the surrounding calling convention costs, like prologue and epilogue code, stack setup and argument passing[5] (see here[6] for more realistic instruction path length, stack and other costs associated with calls on an x86 platform). See also here[7] for a slide presentation by Eric S. Roberts ("The Allocation of Memory to Variables", chapter 7)[8] - illustrating the use of stack and heap memory usage when summing three rational numbers in the Java object oriented language.

Imperative Procedural Object-oriented
 load r;                      1
 r2 = r * r;                  2
 result = r2 * "3.142";       3
.... storage .............
result variable
constant "3.142"

area proc(r2,res):
   push stack                                 5
   load r2;                                   6
   r3 = r2 * r2;                              7
   res = r3 * "3.142";                        8
   pop stack                                  9
   return;                                   10
main proc:
   load r;                                    1
   call area(r,result);
    +load p = address of parameter list;      2
    +load v = address of subroutine 'area';   3
    +goto v with return;                      4
.... storage .............
result variable
constant "3.142" 
parameter list variable
function pointer (==>area)
stack storage

circle.area method(r2):
   push stack                                 7
   load r2;                                   8
   r3 = r2 * r2;                              9
   res = r3 * "3.142";                       10
   pop stack                                 11
   return(res);                           12,13
main proc:
   load r;                                    1
   result = circle.area(r); 
      +allocate heap storage;                 2[See 1]                  
      +copy r to message;                     3
      +load p = address of message;           4
      +load v = addr. of method 'circle.area' 5
      +goto v with return;                    6
.... storage .............
result variable (assumed pre-allocated)
immutable variable "3.142" (final)
(heap) message variable for circle method call
stack storage

  1. ^ See section-"Allocation of dynamic memory for Message storage and object storage"

The advantages of procedural abstraction and object-oriented-style polymorphism are not well illustrated by a small example like the one above. This example is designed principally to illustrate some intrinsic performance differences, not abstraction or code re-use.

Subroutine/Method call overhead

The presence of a (called) subroutine in a program contributes nothing extra to the functionality of the program regardless of paradigm, but may contribute greatly to the structuring and generality of the program, making it much easier to write, modify, and extend.[9] The extent to which different paradigms utilize subroutines (and their consequent memory requirements) influences the overall performance of the complete algorithm, although as Guy Steele pointed out in a 1977 paper, a well-designed programming language implementation can have very low overheads for procedural abstraction (but laments, in most implementations, that they seldom achieve this in practice - being "rather thoughtless or careless in this regard"). In the same paper, Steele also makes a considered case for automata-based programming (utilizing procedure calls with tail recursion) and concludes that "we should have a healthy respect for procedure calls" (because they are powerful) but suggested "use them sparingly"[9]

In terms of the frequency of subroutine calls:-

  • for procedural programming, the granularity of the code is largely determined by the number of discrete procedures or modules.
  • for functional programming, frequent calls to library subroutines are commonplace[citation needed] (but may be frequently inlined by the optimizing compiler)
  • for object oriented programming, the number of method calls invoked is also partly determined by the granularity of the data structures and may therefore include many "read-only" accesses to low level objects that are encapsulated (and therefore accessible in no other, more direct, way). Since increased granularity is a prerequisite for greater code reuse, the tendency is towards fine-grained data structures, and a corresponding increase in the number of discrete objects (and their methods) and, consequently, subroutine calls. The creation of "god objects" is actively discouraged. Constructors also add to the count as they are also subroutine calls (unless they are inlined). Performance problems caused by excessive granularity may not become apparent until scalability becomes an issue.
  • for other paradigms, where a mixture of the above paradigms may be employed, subroutine usage is less predictable.

Allocation of dynamic memory for Message storage and object storage

Uniquely, the object oriented paradigm involves dynamic allocation of memory from heap storage for both object creation and message passing. A 1994 benchmark - "Memory Allocation Costs in Large C and C++ Programs" conducted by Digital Equipment Corporation on a variety of software, using an instruction-level profiling tool, measured how many instructions were required per dynamic storage allocation. The results showed that the lowest absolute number of instructions executed averaged around 50 but others reached as high as 611.[10] See also "Heap:Pleasures and pains" by Murali R. Krishnan[11] that states "Heap implementations tend to stay general for all platforms, and hence have heavy overhead". The above pseudocode example does not include a realistic estimate of this memory allocation pathlength or the memory prefix overheads involved and the subsequent associated garbage collection overheads (To gain some appreciation that heap allocation is not a "trivial" task, this [12] is an example of one open source microallocator by games developer, John W. Ratcliff, consisting of nearly 1,000 lines of code).

Dynamically dispatched Message calls v. Direct procedure Call overheads

In their Abstract "Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis",[13] Jeffrey Dean, David Grove, and Craig Chambers of the Department of Computer Science and Engineering, at the University of Washington, claim that "Heavy use of inheritance and dynamically-bound messages is likely to make code more extensible and reusable, but it also imposes a significant performance overhead, compared to an equivalent but non-extensible program written in a non-object-oriented manner. In some domains, such as structured graphics packages, the performance cost of the extra flexibility provided by using a heavily object-oriented style is acceptable. However, in other domains, such as basic data structure libraries, numerical computing packages, rendering libraries, and trace-driven simulation frameworks, the cost of message passing can be too great, forcing the programmer to avoid object-oriented programming in the “hot spots” of their application."

Serialization of objects

Serialization imposes quite considerable overheads when passing objects from one system to another, especially when the transfer is in human-readable formats such as XML and JSON. This contrasts with compact binary formats for non object oriented data. Both encoding and decoding of the objects data value and its attributes are involved in the serialization process (that also includes awareness of complex issues such as inheritance, encapsulation and data hiding).

See also


  1. ^ Jacobs, B. (2006-08-27). "Object Oriented Programming Oversold". Archived from the original on 2006-10-15. 
  2. ^ Shelly, Asaf (2008-08-22). "Flaws of Object Oriented Modeling". Intel® Software Network. Retrieved 2010-07-04. 
  3. ^ Yegge, Steve (2006-03-30). "Execution in the Kingdom of Nouns". Retrieved 2010-07-03. 
  4. ^ "The Jargon File v4.4.7: "syntactic sugar"". 
  5. ^ "The True Cost of Calls". 2008-12-30. 
  6. ^
  7. ^ Roberts, Eric S. (2008). "Art and Science of Java; Chapter 7: Objects and Memory". Stanford University. 
  8. ^ Roberts, Eric S. (2008). Art and Science of Java. Addison-Wesley. ISBN 978-0321486127. 
  9. ^ a b Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [1][2][3]
  10. ^ David Detlefs and Al Dosser and Benjamin Zorn (1994-06). "Memory Allocation Costs in Large C and C++ Programs; Page 532" (PDF). SOFTWARE—PRACTICE AND EXPERIENCE 24 (6): 527–542. )
  11. ^ Krishnan, Murali R. (1999-02). "Heap: Pleasures and pains". 
  12. ^
  13. ^ Jeffrey Dean, David Grove, and Craig Chambers. Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis. University of Washington. doi: 

Further reading

External links

Wikimedia Foundation. 2010.

Игры ⚽ Нужно сделать НИР?

Look at other dictionaries:

  • Comparison of programming languages — Programming language comparisons General comparison Basic syntax Basic instructions Arrays Associative arrays String operations …   Wikipedia

  • Programming paradigm — Programming paradigms Agent oriented Automata based Component based Flow based Pipelined Concatenative Concu …   Wikipedia

  • Programming language — lists Alphabetical Categorical Chronological Generational A programming language is an artificial language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs that… …   Wikipedia

  • Object-oriented programming — Programming paradigms Agent oriented Automata based Component based Flow based Pipelined Concatenative Concurrent computing …   Wikipedia

  • Declarative programming — Programming paradigms Agent oriented Automata based Component based Flow based Pipelined Concatenative Concurrent computing …   Wikipedia

  • Event-driven programming — Programming paradigms Agent oriented Automata based Component based Flow based Pipelined Concatenative Concurrent computin …   Wikipedia

  • Comparison of agent-based modeling software — In the last few years, the agent based modeling (ABM) community has developed several practical agent based modeling toolkits that enable individuals to develop agent based applications. More and more such toolkits are coming into existence, and… …   Wikipedia

  • Python (programming language) — infobox programming language name = Python paradigm = multi paradigm: object oriented, imperative, functional year = 1991 designer = Guido van Rossum developer = Python Software Foundation latest release version = 2.6 latest release date =… …   Wikipedia

  • D (programming language) — For other programming languages named D, see D (disambiguation)#Computing. D programming language Paradigm(s) multi paradigm: imperative, object oriented, functional, meta Appeared in 1999 (1999) Designed by …   Wikipedia

  • History of programming languages — This article discusses the major developments in the history of programming languages. For a detailed timeline of events, see the timeline of programming languages. History of Programming Languages The first programming languages predate the… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”