There are certain words and phrases that create echoes that persist long after I first encounter them. This one has been bouncing around in my head lately.
Orthogonality is a concept I first encountered during a computer science class in university. The idea of it was so important to my professor that its definition became a question on an exam, so I memorized it like a good student would. I've since forgotten what it means, of course, and I'm not sure I ever fully grasped the concept in a meaningful way. But I can change that. So, let's start with the definition.
Which definition?
The most commonly-understood definition of orthogonality might be that from mathematics:
orthogonality
noun
- The quality of lying or intersecting at right angles.
- The relation of opposition between things at right angles.
And this is the definition that first comes to mind when I think of the term. But that's not the meaning that I needed to memorize. In programming language design, orthogonality has its own loosely-related definition. Allow me a moment to dust off my textbook...
Orthogonality means that features can be used in any combination, the combinations all make sense, and the meaning of a given feature is consistent, regardless of the other features with which it is combined.
Programming Language Pragmatics (3rd ed.) page 228, Michael L. Scott
This definition is provided in the context of expression evaluation and control flow. The author explains that the term relates to mathematics:
The name is meant to draw an explicit analogy to orthogonal vectors in linear algebra: none of the vectors in an orthogonal set depends on (or can be expressed in terms of) the others, and all are needed in order to describe the vector space as a whole.
That's a perfectly good explanation of where the word comes from, but it doesn't actually help me understand the idea. If anything, it replaces one unfamiliar concept with another. But you don't need to understand linear algebra to understand orthogonality in programming (which is fortunate because I've forgotten much of what I learned in that class too).
Demonstrating orthogonality
Let's imagine we're designing a simple drawing program. We'll use it to examine Scott's definition one piece at a time. Our program will include a handful of simple features:
- colors
- brushes
- layers
- opacity
These features are intended to be used together. A user picks a color, selects a brush, adjusts the opacity, and paints on a layer. Intuition tells us that each feature should have a single responsibility; any changes made to one feature should not affect the use of any other feature. For example, changing the brush type shouldn't also change the color.
Now consider the definition of orthogonality within the context of our program:
Features can be used in any combination
Our drawing program lets us choose any brush with any color and paint on any layer at any opacity. Imagine if certain brushes could only be used on the background layer, or if the opacity slider became disabled whenever the color red is selected. Those aren't technical impossibilities; they're arbitrary restrictions. Every unnecessary restriction is another rule the user has to remember and work around.
The combinations all make sense
Imagine painting with a semi-transparent brush on a separate layer. We expect each feature to contribute its own behavior. The brush determines how paint is applied, the opacity controls how transparent that paint is, and the layer determines where it is stored. Together, they produce exactly the result we'd predict.
Contrast that with a design where lowering the opacity also changes the active layer, or selecting a particular brush automatically disables transparency. The features could still be combined, but the result would be surprising. Orthogonal features should work together, not interfere with one another.
The meaning of a given feature is consistent
Finally, consider layers. Their purpose is simple: to separate independent parts of a drawing. That purpose shouldn't change based on which other features are being used alongside them. A layer remains a layer whether the brush is opaque or transparent, large or small.
This is the consistency Scott describes in his definition. Once a feature has a well-defined meaning, that meaning should remain stable regardless of context.
So why is orthogonality a desirable property?
Our drawing program isn't orthogonal because it has brushes and layers. It's orthogonal because every feature has a single, predictable purpose. Those features can be freely combined, and combining them never changes what an individual feature means.
Programming languages strive for the same property. Like our drawing program, they become easier to learn and use when their features can be freely combined, interact predictably, and retain their meaning regardless of context.
The more orthogonal a programming language is, the fewer exceptions programmers need to remember. Instead of memorizing special cases, they can rely on a small set of consistent principles that apply throughout the language. That makes programs easier to read, easier to reason about, and ultimately easier to write.
Orthogonality in practice
It's one thing to talk about orthogonality in the abstract, but what does it actually look like in a programming language? We can look to Python for a good example. The language is often described as one where "everything is an object," and that philosophy contributes heavily to its consistency. MJ Michael explains:
The statement “everything is an object in Python” is far more than a casual observation — it is the cornerstone of Python’s entire design philosophy. From integers and strings to functions, classes, modules, and even
None, every entity in Python shares the same fundamental nature: it is an instance of a class, it has an identity, a type, and a value.This unified object model is what gives Python its remarkable consistency. The same rules apply everywhere. The same tools work on every value. The same patterns repeat themselves throughout the language. Once you internalize this, Python starts to feel less like a collection of features and more like a cohesive, elegant system.
We can see this philosophy in action:
>>> type(1)
<class 'int'>
>>> type("hello")
<class 'str'>
>>> type(len)
<class 'builtin_function_or_method'>
>>> type(None)
<class 'NoneType'>
Integers, strings, functions, and even None all participate in the same object model. They serve different purposes, but they all follow the same fundamental rules.
Because those rules apply consistently throughout the language, programmers spend less time memorizing exceptions and more time applying what they already know. That's exactly the kind of consistency Scott describes in his definition of orthogonality.
Orthogonality isn't the only goal
If orthogonality is such a desirable property, why not maximize it? As with most aspects of language design, the answer is that orthogonality exists alongside other goals. Features that combine freely and consistently can make a language elegant, but they don't always make it easier to use correctly.
Scott offers a classic example from C:
In any context that would require a Boolean value in other languages, C accepts an integer (or anything that can be coerced to be an integer). It interprets zero as false; any other value is true. As a result, both of the following constructs are valid—common—in C:
if (a == b) { /* do the following if a equals b */ if (a = b) { /* assign b into a and then do the following if the result is nonzero */Programming Language Pragmatics (3rd ed.) page 229, Michael L. Scott
In C, assignment is an expression, and expressions are valid conditions. From a purely orthogonal perspective, that design is consistent: if assignment produces a value, why shouldn't it be usable anywhere another expression is expected?
The downside is that this consistency also makes a common typo perfectly legal. Accidentally writing = instead of == doesn't produce a compiler error. Instead, the program compiles successfully and quietly does the wrong thing.
In this case, the language's permissiveness comes at the expense of catching a likely mistake. Many newer languages deliberately reject or warn about code like this, sacrificing a small amount of orthogonality in favor of readability and safety. Sometimes, intentionally restricting what a programmer can do leads to clearer, safer code.
Putting it all together
Looking back, I think what confused me wasn't the definition itself. It was that I was trying to memorize it instead of understand it. Orthogonality isn't about right angles, nor is it simply about using features together. It's about reducing surprise. A programmer should be able to learn how one feature works, combine it freely with others, and trust that it will continue to behave the same way. That's what makes a language feel coherent instead of like a collection of unrelated rules.
That's what my professor was trying to get me to understand.