It's like describing colors using "redness" and "maroonness". If you increase the maroonness of a color, you affect the redness. You can still get any color you want, but you have to adjust how you use both features at the same time. Visually, they would be two axes that have something other than 90 degrees between them.

One thing I'm noticing from others' comments in this thread is that people seem to think of perl as orthogonal. Bull! Y'all just want to say that because you've been trained that orthogonality is always good, and therefore perl must be orthogonal. Perl is one of the least orthogonal programming languages I know. It's still far more orthogonal than any human language I know, which raises an interesting question: why are human languages, which are much easier to mutate and have much lower backwards-compatibility requirements, not mathematically beautiful and orthogonal?

I venture that orthogonality of expression is unnatural to us meat brains. The mathematical advantages are real enough that we make programming languages as orthogonal as we can tolerate, but those languages that sacrifice intuitive expressibility at the altar of orthogonality are the niche languages that are largely ignored, their fanatical followers notwithstanding.

I'm not saying orthogonality is bad. It's not; it's absolutely necessary for large-scale development, and it's the best way of reducing the raw amount of stuff you have to keep in your head at one time to use a language. (Think of the English grammatical rules for past participles -- is it "have drank"? "have drunk"? "drinken"?) But we don't think of things as tasting 20% salty, 8% bitter, 32% sweet, etc. We just think it tastes like chicken.

Update:Oh, right. You're not tilly, are you? All the colors and blinking lights and voices in my head confused me.

I find it really interesting that people keep considering orthogonality in the context of languages. Ive never thought about languages being orthogonal or not. To me orthogonal only applies to solutions (algorithms etc.) and not to the language the solutions are implemented in.

Fo instance you compare while (<>) with for and discuss their orthogonality. These are flow control structures and not solutions and thus to me to discuss their orthogonality is meaningless. I mean if I have

while (<>) {
  my $hexstr="";
  foreach (split //) {
    $hexstr.=sprintf"02X",ord;
  }
  print $hexstr;
}
[download]

Then the loops are not orthogonal. I cannot make an arbitrary change to either without considering the effect on the other (at the bare minimun the inside loop affects the outside by changing $_, and obviously the inside is dependant on the <> operator).

But if i rewrite that as such:

 
  sub as_hexstr {
    local $_=shift;
    my $hexstr="";
    foreach (split //) {
      $hexstr.=sprintf"02X",ord;
    }
    return $hexstr;
  }

  while (<>) {
    print as_hexstr($_);
  }
[download]

Now the loops _are_ orthogonal. I can make arbitrary changes to either without effecting the other in the slightest. So to me a control structure is never explicity orthogonal or not to another control structure. It is only when the two structures are _used_ to achieve a goal that their orthogonality may be discussed with any meaning.

Perhaps im missing something here, if so then hopefully you or one of the other monks who has thought about the orthogonality of languages can straighten me out....

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

To me orthogonal only applies to solutions (algorithms etc.) and not to the language the solutions are implemented in.

Take one large step back. Designing a programming language is just another problem. Perl and Python are just two solutions, with Perl being the least orthogonal of the two.