Re: argument about encapsulating data sublanguage

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 28 Dec 2006 23:21:57 GMT
Message-ID: <pkYkh.38193$cz.562026@ursa-nb00s0.nbnet.nb.ca>

Gene Wirchenko wrote:

> "Marshall" <marshall.spight_at_gmail.com> wrote:
> 
> 

>>On Dec 28, 11:39 am, Gene Wirchenko <g..._at_ocis.net> wrote:
>>
>>>"Marshall" <marshall.spi..._at_gmail.com> wrote:
>>>
>>>
>>>>Consider that most OOPLs, such as Java, contain a mix of notations.
>>>>Both the modern OO notation "x.f(y)" and the old-fashioned math
>>>>notation "x + y" are supported. But why should we continue to
>>>>use such a low-level way of doing things?
>>>
>>> OTOH, x.f(y) is typical hierarchical chauvinism oppressing y
>>>merely because it is second. Have we not grown past that? Can we not
>>>have relationships between equals: x+y?
>>
>>But in "x+y", the y still comes second! That's not equal!

> 
> 
>     But remember commutivity!  x+y to y+x is a valid transform. x.f(y)
> to y.f(x) might not be.
> 
> 

>>You have reminded me of something the hollywood movies do
>>when faced with two stars of the first magnitude, and the
>>problem of how to give them equal credit. One gets the
>>leftmost position, and one gets the topmost position. This
>>will require a 2 dimensional syntax:
>>
>>+y
>>x
>>
>>It works well, don't you think?

> 
> 
>      For simple subexpressions, but something like
>           +(a*b)
>           (c*d)
> no.  Maybe, I should restate that as
>           + *b
>             a
>           *d
>           c 
> I will stop at this point, or someone will take this and start a new
> fad of POET (Pictorially-Oriented Expression Tool).

There is a limitation with this approach. What happens when three equally A-list stars show up in the same movie in comparably important roles?

I think you have to add motion with the text scrolling in reverse order just to get to three. One appears first, one appears leftmost and one appears on top.

>>>>Best of all, this lets me avoid sprinkling math formulas throughout
>>>>my code. Yuck! That stuff needs to be segregated off in one
>>>>place, so it doesn't gum up the works like so much sand.
>>>
>>>Have you figured out a way to avoid sprinkling logic throughout
>>>code? Many people do not seem to like logic much, and you would be
>>>doing them a favour.
>>
>>An excellent question! I shall work on it.
> He/She has prejudices. Received on Thu Dec 28 2006 - 17:21:57 CST