Comparison of programming paradigms

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Comparison of programming paradigms" – news · newspapers · books · scholar · JSTOR (August 2015) (Learn how and when to remove this message) This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (August 2015) (Learn how and when to remove this message) (Learn how and when to remove this message)

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 extant Wikipedia articles.

Main paradigm approaches

There are two main approaches to programming:^[1]

• statements that change a program state
  .
• Declarative programming – focuses on what to execute, defines program logic, but not detailed control flow.

The following are widely considered the main programming paradigms, as seen when measuring programming language popularity:

• Procedural programming – specifies the steps a program must take to reach a desired state.
• state and mutable
  data.
• methods
  together with their interactions.

• threads
  .
• Automata-based programming – a program, or part, is treated as a model of a finite state machine or any other formal automaton.
• Reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change.

The subroutines that implement OOP methods may be ultimately coded in an imperative, functional, or procedural style that may, or may not, directly alter state on behalf of the invoking program. There is some overlap between paradigms, inevitably, but the main features or identifiable differences are summarized in this table:

Differences in terminology

Despite multiple (types of) programming

Syntactic sugar is the sweetening of program functionality by introducing language features that facilitate a given usage, even if the result could be achieved without them. One example of syntactic sugar may arguably be the classes used in object-oriented programming languages. The imperative language C can support object-oriented programming via 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 (and other procedural and structured programming languages) could be considered syntactic sugar. Assembly language can support procedural or structured programming via 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 language C# (C Sharp), such as properties and interfaces, similarly enable no new functions, but are designed to make good programming practices more prominent and natural.

Some programmers feel that these features are unimportant or even frivolous. For example,

An extension of this is the syntactic saccharin, or gratuitous syntax that does not make programming easier.^[11]

Performance comparison

In total

For programs executing in a managed code environment, such as the .NET framework, many issues affect performance that are significantly affected by the programming language paradigm and various language features used.^[12]

Pseudocode examples comparing various paradigms

A

 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
vtable(==>area)
stack storage

The advantages of procedural abstraction and object-oriented-style polymorphism are poorly illustrated by a small example like the one above. This example is designed mainly 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.

• 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 common,^{[citation needed]} but may be often 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 thus include many read-only accesses to low level objects that are encapsulated, and thus accessible in no other, more direct, way. Since increased granularity is a prerequisite for greater code reuse, the tendency is toward 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 mix of the above paradigms may be employed, subroutine use is less predictable.

Allocation of dynamic memory for message and object storage

Uniquely, the object-oriented paradigm involves

In their Abstract "Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis",[22] 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, relative 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."

Serializing objects

Serialization imposes large overheads when passing objects from one system to another, especially when the transfer is in human-readable formats such as Extensible Markup Language (XML) and JavaScript Object Notation (JSON). This contrasts with compact binary formats for non-object-oriented data. Both encoding and decoding of the object's data value and its attributes are involved in the serializing process, which also includes awareness of complex issues such as inheriting, encapsulating, and data hiding.

Parallel computing

• Comparison of programming languages
• Comparison of programming languages (basic instructions)
• Granularity#Computing
• Message passing
• Subroutine

References