digitalmars.D - What is orthogonality?

• Bill Baxter (36/36) Oct 18 2006 The world orthogonality has been thrown around a bit here, me included.
• rm (6/49) Oct 18 2006 IMHO - in the C++ world - STL is a much better example of orthogonality.
• Karen Lanrap (10/13) Oct 19 2006 He says something similar himself:
• Bruno Medeiros (21/64) Oct 24 2006 Hey, that's a pretty good comment. I subscribe exactly! When I think or
Bill Baxter <dnewsgroup billbaxter.com> writes:
The world orthogonality has been thrown around a bit here, me included.
I just read this interesting interview with Matz, Ruby's creator where
he says he doesn't like orthogonality and gives an example of why it's bad:

"An example of orthogonality is allowing any combination of small
features or syntax. For example, C++ supports both default parameter
parameters. Both are good features to have in a language, but because
they are orthogonal, you can apply both at the same time. The compiler
knows how to apply both at the same time. If it's ambiguous, the
compiler will flag an error. But if I look at the code, I need to apply
the rule with my brain too. I need to guess how the compiler works. If
I'm right, and I'm smart enough, it's no problem. But if I'm not smart
enough, and I'm really not, it causes confusion. The result will be
unexpected for an ordinary person. This is an example of how

First a definition. My concept of orthogonal comes mostly from linear
algebra.  If you have two vectors that are orthogonal there is no
component of one that can be represented using the other.  I.e. the
projection of one onto the other is zero.  They have zero overlap.

What Matz is talking about is more like "syntactic orthogonality".  The
syntax of those two features is orthogonal so they can coexist without
issues.  The syntax subspaces they cover have zero overlap.

That's important, but I think a low-level kind of orthogonality.  What
I'm talking about is more of a "semantic orthogonality".  What does the
feature let you express?  In the semantic sense his example of
parameters is exactly 100% UN-orthogonal.  They both achieve exactly the
same behavior.  They overlap 100% in terms of what you can express.

In the end he says he wants things to be "harmonious", which I think is
more or less equivalent to "semantically orthogonal".  Harmonious in the
sense that I do my job and you do yours, and we don't step on each
other's toes.  But that's precisely what orthogonality is -- not
overlapping.

The full interview is here:
http://www.artima.com/intv/ruby.html

--bb
Oct 18 2006
rm <roel.mathys gmail.com> writes:
Bill Baxter wrote:
The world orthogonality has been thrown around a bit here, me included.
I just read this interesting interview with Matz, Ruby's creator where
he says he doesn't like orthogonality and gives an example of why it's bad:

"An example of orthogonality is allowing any combination of small
features or syntax. For example, C++ supports both default parameter
parameters. Both are good features to have in a language, but because
they are orthogonal, you can apply both at the same time. The compiler
knows how to apply both at the same time. If it's ambiguous, the
compiler will flag an error. But if I look at the code, I need to apply
the rule with my brain too. I need to guess how the compiler works. If
I'm right, and I'm smart enough, it's no problem. But if I'm not smart
enough, and I'm really not, it causes confusion. The result will be
unexpected for an ordinary person. This is an example of how

First a definition. My concept of orthogonal comes mostly from linear
algebra.  If you have two vectors that are orthogonal there is no
component of one that can be represented using the other.  I.e. the
projection of one onto the other is zero.  They have zero overlap.

What Matz is talking about is more like "syntactic orthogonality".  The
syntax of those two features is orthogonal so they can coexist without
issues.  The syntax subspaces they cover have zero overlap.

That's important, but I think a low-level kind of orthogonality.  What
I'm talking about is more of a "semantic orthogonality".  What does the
feature let you express?  In the semantic sense his example of
parameters is exactly 100% UN-orthogonal.  They both achieve exactly the
same behavior.  They overlap 100% in terms of what you can express.

In the end he says he wants things to be "harmonious", which I think is
more or less equivalent to "semantically orthogonal".  Harmonious in the
sense that I do my job and you do yours, and we don't step on each
other's toes.  But that's precisely what orthogonality is -- not
overlapping.

The full interview is here:
http://www.artima.com/intv/ruby.html

--bb
IMHO - in the C++ world - STL is a much better example of orthogonality. e.g. the algorithms and containers are type independent. So a sort algorithm for a vector containing ints can be the same as for a vector containing chars. roel
Oct 18 2006
Karen Lanrap <karen digitaldaemon.com> writes:
Bill Baxter wrote:

In the semantic sense his example of
parameters is exactly 100% UN-orthogonal.
He says something similar himself: | You need to pick one of them, even though both are good. But your question is still legitimate, because of the turing completeness of general purpose languages every claim of orthogonality has to be evaluated on some level of abstraction above the needed features for turing compatibilty. If there is no agreement on the level of abstraction there is no absolute orthogonality. All one can state then is, that some feature is relatively orthogonal to some other feature.
Oct 19 2006
Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
The world orthogonality has been thrown around a bit here, me included.
I just read this interesting interview with Matz, Ruby's creator where
he says he doesn't like orthogonality and gives an example of why it's bad:

"An example of orthogonality is allowing any combination of small
features or syntax. For example, C++ supports both default parameter
parameters. Both are good features to have in a language, but because
they are orthogonal, you can apply both at the same time. The compiler
knows how to apply both at the same time. If it's ambiguous, the
compiler will flag an error. But if I look at the code, I need to apply
the rule with my brain too. I need to guess how the compiler works. If
I'm right, and I'm smart enough, it's no problem. But if I'm not smart
enough, and I'm really not, it causes confusion. The result will be
unexpected for an ordinary person. This is an example of how

First a definition. My concept of orthogonal comes mostly from linear
algebra.  If you have two vectors that are orthogonal there is no
component of one that can be represented using the other.  I.e. the
projection of one onto the other is zero.  They have zero overlap.

What Matz is talking about is more like "syntactic orthogonality".  The
syntax of those two features is orthogonal so they can coexist without
issues.  The syntax subspaces they cover have zero overlap.

That's important, but I think a low-level kind of orthogonality.  What
I'm talking about is more of a "semantic orthogonality".  What does the
feature let you express?  In the semantic sense his example of
parameters is exactly 100% UN-orthogonal.  They both achieve exactly the
same behavior.  They overlap 100% in terms of what you can express.

In the end he says he wants things to be "harmonious", which I think is
more or less equivalent to "semantically orthogonal".  Harmonious in the
sense that I do my job and you do yours, and we don't step on each
other's toes.  But that's precisely what orthogonality is -- not
overlapping.

The full interview is here:
http://www.artima.com/intv/ruby.html

--bb
Hey, that's a pretty good comment. I subscribe exactly! When I think or speak of orthogonality it's usually not in the sense of merely allowing combinations of features(syntactic orthogonality, like you said), but instead, such additions and/or combination of features much result in a system/behavior which is as simple, or simpler, than the alternative. If instead such modifications result in a system which is more complicated, harder to explain, has more special cases, etc., then it is not good "orthogonality" (i.e., it does not have semantic orthogonality). Whenever power, expressiveness or elegance is not harmed, a language (or any system for that matter) should strive for more orthogonality. One reason is because it becomes simpler to explain and understand, but also because sometimes more orthogonality results in more of those 3 aforementioned qualities. On example of what I(and others) think is a severe breach of orthogonality in D are static arrays. Static arrays are a legacy C construct/design which should have no place in modern languages(in particular D) with their current behavior (broken value types). -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 24 2006