From: "Randy W. Sims" <ml-ruby@...>
Date: 2004-10-11T01:15:33+09:00
Subject: Re: ANN: Free-form-operators patch

On 10/10/2004 11:30 AM, trans. (T. Onoma) wrote:
> On Sunday 10 October 2004 10:55 am, Randy W. Sims wrote:
> | On 10/10/2004 10:01 AM, trans. (T. Onoma) wrote:
> | > Know what noise is? Another word for static. Know what static is?
> | > Something that never changes. You know what something that never changes
> | > is?
> |
> | S T A B L E
> |
> | D E P E N D A B L E
> |
> | C O M P A T I B L E
> |
> | Like standards based languages: C, C++, Ada, etc.
> |
> | Actually, this is the wrong argument. I don't think anyone is against
> | change. But some of us feel that there are some potential problems or
> | dangers associated with this particular change.
> 
> I understand. Actually I've had a notion in the back of my head for awhile 
> about this. Seems to me developers might be better off if they followed 
> parallel tracks rather then serial tracks. Diagram:
> 
>   Serial Model
> 
>   0.x -> 1.0 -> 1.1 -> ... -> 2.0 -> 2.1 -> ... -> 3.0 -> ...
> 
>   
>   Parallel Model
> 
>   0.x -> 1.0 -> 1.1 -> ... -> 1.x
>           |
>           V
>          2.0 -> 2.1 -> ... -> 2.x
>           |
>           V
>          3.0 -> ...
> 
> The idea is that bug-fixes and compatible-only changes move from left to 
> right, all and others move down.  The only project I know that sort-of does 
> this much is Linux, but even there we see a lot of back porting and what not.
> 
> | A long time ago I was reading one of Bjarne Stroustrup's books or on his
> | website where he proposed user defined operators. At the time I was
> | excited about it and looked forward to it. Unicode provides lots of neat
> | symbols that would make meaningful operators. If this patch allowed
> | that, I might be more inclined to agree with it. But that's the heart of
> | the problem: assigning meaning to an arbitrary combination of symbols
> | makes the resulting code hard to interpret. Among the objections listed,
> | I think this is the hardest to overcome. Some have compared operators to
> | methods, but that comparison doesn't really hold. IMO the only
> | comparison there is if you used method names like 'sdkjfo' - arbitrary
> | combinations of characters with no inherant semantics.
> 
> I think there is a balance to be found. Many of us has wanted an extra 
> operator for this or that at one time or another. I tend to think that they 
> would be used sparingly if available for precisely the reasons people 
> suggested against them --but the "hard to read" arguments don't really 
> convince me that it wouldn't be a good feature --in fact in some cases it 
> would even make code clearer. And in fact that's why some people want this 
> feature --not to obscure code, but to actually make it easier to read.

I think we are mostly in agreement. It's all about balance. For example 
the notation you used above in reference to versions conveys meaningful 
information. (But let's hope no one actually tries to implement 
vertically oriented operators. ;-) I just worry about abuses. How much 
rope do you give the programmer? It's not always obvious. I guess I tend 
to be more on the conservative side. When I first started learning Perl, 
I thought I would hate it. Too much excess. Too many ways to say the 
same thing. Coming from C/C++, I believed the core language should be as 
small as possible so as to reduce comlexity, to be well-defined. Perl 
turned out to be one of my favorite languages. So, I'm not completely 
closed to the idea; I just have concerns.

Randy.