in reply to Re: (OT) On Orthogonality
in thread (OT) On Orthogonality

I agree with FoxtrotUniform; I also think of orthogonality mostly in terms of the mathematical definition. But I want to expand on those orthogonal vectors. Take a counterexample: say you have two features that interact. Like perl's for loop and the magical while diamond while(<>). Now try to lay those two features out in a plane at right angles to each other, so that they become the x and y axes of a two-dimensional space. Notice how if you use one feature, you can't use the other feature in exactly the same way. You want to use the default $_ variable from the while loop, but oops -- you're inside the for loop and it aliased $_ to something else. You can still use the full power of both constructs, but you have to modify your use of one to accommodate the other. Going back to the axes, moving on one axis also moves you on the other.

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.

Replies are listed 'Best First'.
Re: Re: (FoxUni) Re: (OT) On Orthogonality
by demerphq (Chancellor) on Apr 17, 2002 at 10:01 UTC
    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.

[reply]
[d/l]
[select]
      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.

[reply]
        Designing a programming language is just another problem.

        Agreed, so there are parts of the implementation of that language that are orthogonal to some other parts and parts that arent. But aspects of the language created will be orthogonal with respect to others depending on how they are used.

        To me what you just said is "Designing a truck is just another problem. Fords and GMs are just two solutions..."

        Again maybe ive missed something but you havent explained what it is.... :-)

        Hmm, on reflection maybe people mean

        Language X has more features that are orthogonal with respect to its other features than language Y.

        Is that what you mean?

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

[reply]

In Section Meditations