Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Jump to content

Orthogonality (programming)

From Wikipedia, the free encyclopedia

In computer programming, orthogonality means that operations change just one thing without affecting others.[1] The term is most-frequently used regarding assembly instruction sets, as orthogonal instruction set.

Orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number of ways to build the control and data structures of the language.[2] It is associated with simplicity; the more orthogonal the design, the fewer exceptions. This makes it easier to learn, read and write programs in a programming language[citation needed]. The meaning of an orthogonal feature is independent of context; the key parameters are symmetry and consistency (for example, a pointer is an orthogonal concept).

An example from IBM Mainframe and VAX highlights this concept. An IBM mainframe has two different instructions for adding the contents of a register to a memory cell (or another register). These statements are shown below:

A Reg1, memory_cell
AR Reg1, Reg2

In the first case, the contents of Reg1 are added to the contents of a memory cell; the result is stored in Reg1. In the second case, the contents of Reg1 are added to the contents of another register (Reg2) and the result is stored in Reg1.

In contrast to the above set of statements, VAX has only one statement for addition:

ADDL operand1, operand2

In this case the two operands (operand1 and operand2) can be registers, memory cells, or a combination of both; the instruction adds the contents of operand1 to the contents of operand2, storing the result in operand1.

VAX's instruction for addition is more orthogonal than the instructions provided by IBM; hence, it is easier for the programmer to remember (and use) the one provided by VAX.

The Revised Report on the Algorithmic Language Algol 68 had this to say about "Orthogonal design":

The number of independent primitive concepts has been minimized in order that the language be easy to describe, to learn, and to implement. On the other hand, these concepts have been applied "orthogonally" in order to maximize the expressive power of the language while trying to avoid deleterious superfluities.

The design of C language may be examined from the perspective of orthogonality. The C language is somewhat inconsistent in its treatment of concepts and language structure, making it difficult for the user to learn (and use) the language. Examples of exceptions follow:

  • Structures (but not arrays) may be returned from a function.
  • An array can be returned if it is inside a structure.
  • A member of a structure can be any data type (except void, or the structure of the same type).
  • An array element can be any data type (except void).
  • Everything is passed by value (except arrays).

Though this concept was first applied to programming languages, orthogonality has since become recognized as a valuable feature in the design of APIs and even user interfaces. There, too, having a small set of composable primitive operations without surprising cross-linkages is valuable, as it leads to systems that are easier to explain and less frustrating to use.

On the other hand, orthogonality does not necessarily result in simpler systems, as the example of IBM and VAX instructions shows — in the end, the less orthogonal RISC CPU architectures were more successful than the CISC architectures.

See also

[edit]

References

[edit]
  1. ^ "Compactness and Orthogonality". www.catb.org. Retrieved 2018-04-06.
  2. ^ Sebesta, Robert W. (2010). Concepts of programming languages (9th ed.). Boston: Addison-Wesley. p. 10. ISBN 9780136073475. OCLC 268788303.

Further reading

[edit]
  • The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. Addison-Wesley. 2000. ISBN 978-0-201-61622-4.
  • A. van Wijngaarden, Orthogonal Design and Description of a Formal Language, Mathematisch Centrum, Amsterdam, MR 76, October 1965.
[edit]