## Friday, August 13, 2010

### Orthogonality

Literally orthogonality means at right angles, hence independent or irrelevant to.

In programming languages, orthogonality means design so that changes in one thing don’t effect another. The example they give a user interface and database — you should be able to swap the database without changing the interface or make changes to the interface without affecting the database.

When this term is used in describing computer instruction sets, orgothogonal instruction set can use any register for any purpose while in non-orthogonal set (such as the Intel Pentium), each register has special properties, e. g. only CX can be used for counting string loops.

So non-orthogonality means exceptions to the general language rules, which make it harder to learn. It means that you cannot combine language features in all possible ways. Excessive orthogonality makes it possible to say silly things in the language that complicate the compilers.

Here are some examples of non-orthogonality in C:

1. C has two kinds of built-in data structures, arrays and records (structs). Records can be returned from functions, but arrays cannot.
2. A member of a struct can have any type except void or a structure of the same type.
3. An array element can be any data type except void or a function.
4. Parameters are passed by value, unless they are arrays, in which case they are passed by reference.
5. a+b usually means that they are added, unless a is a pointer the value of b may be changed before the addition takes place.

Orthogonality is one of the most important properties that can help make even complex designs compact. In a purely orthogonal design, operations do not have side effects; each action (whether it's an API call, a macro invocation, or a language operation) changes just one thing without affecting others. There is one and only one way to change each property of whatever system you are controlling.

Eg. computer monitor has orthogonal controls. Its brightness can be changed independently of the contrast level, and (if the monitor has one) the color balance control will be independent of both. Otherwise it would have been difficult to adjust a monitor on which the brightness knob affected the color balance: you'd have to compensate by tweaking the color balance every time after you changed the brightness.

Orthogonality reduces test and development time, because it's easier to verify code that neither causes side effects nor depends on side effects from other code — there are fewer combinations to test. If it breaks, orthogonal code is more easily replaced without disturbance to the rest of the system. Finally, orthogonal code is easier to document and reuse.

The concept of refactoring, which first emerged as an explicit idea from the ‘Extreme Programming’ school, is closely related to orthogonality. To refactor code is to change its structure and organization without changing its observable behavior.

Java and orthogonality
Java is orthogonal in various cases where c or cpp fails. Here are some cases of Java as orthogonal language.
Egs.
1. C has two kinds of built-in data structures, arrays and records (structs and classes also in cpp). Records can be returned from functions, but arrays cannot. But in case arrays can also be returned.
2. We have to check whether a combination of keywords/constructs that could affect each other when used simultaneously on an identifier. For example when applying `public` and `static` to a method, they do not interfere with each other, so these two are orthogonal.

Unix and orthogonality
Unix is praised for its design being orthogonal.

Eg. File is opened for write access without exclusive-locking it for write, for example; This is not the case with every operating system. Old-style (System III) signals were non-orthogonal, because signal receipt had the side-effect of resetting the signal handler to the default die-on-receipt. There are large non-orthogonal patches like the BSD sockets API and very large ones like the X windowing system's drawing libraries.

But on the whole the Unix API is a good example: Otherwise it not only would not but could not be so widely imitated by C libraries on other operating systems. This is also a reason that the Unix API repays study even if you are not a Unix programmer; it has lessons about orthogonality to teach.