Hi --

On Sun, 20 Mar 2005, gabriele renzi wrote:

> Aredridel ha scritto:
>> On Sun, Mar 20, 2005 at 06:50:04AM +0900, Yukihiro Matsumoto wrote:
>> 
>>> Hi,
>>> 
>>> In message "Re: Paul Graham recommends Ruby"
>>>    on Sun, 20 Mar 2005 05:42:59 +0900, "David A. Black" 
>>> <dblack / wobblini.net> writes:
>>> 
>>> |Matz: can you clarify where this is going?
>>> 
>>> Nowhere.  I'm just experimenting new syntax, such as
>>> 
>>>  * a lambda without "lambda"
>>>  * call without "call"
>>>  * explicit block local variables
>>>  * etc.
>>> 
>>> They are fragile by nature.  They might be removed in the future.
>> 
>> 
>> I rather like the idea of a lambda without lambda, and moreso the call
>> without #call. 	I can see the fragility, but I've wanted it. I'd love 
>> it
>> if it's possible without wrecking things.
>
> I agree, even if I think a little messing up it's ok, if the stuff that gets 
> broken is in remote corners. I don't expect ruby to be the same for  ever.

I don't think anyone does.  But that doesn't mean that every aspect of
its design has to have a countdown to removal or change, nor that new
things have to be added to it constantly.  It *is* a good programming
language, you know :-)

In any case, I'm not concerned about things breaking at 2.0.  For me,
these "x without x" things are more a matter of too many shortcuts
and additions that don't feel entirely integral with the language.

For example, {|| } (lambda without lambda).  For me, the question is
not whether it's possible to understand it (which it is).  Rather,
the question is: if Ruby had been designed from the ground up with a
literal function constructor, would it have been {|| } ?  If so, then
fine.  If not, then {|| } would be an add-on that is not properly
integrated into the language.

And if the language really needs a literal function constructor, then
the best possible one should be chosen and everything else should be
rolled back until that constructor can be accomodated.  And if too
much is rolled back -- if the language overall suffers -- then it
shouldn't be done.

I *think* that this is reasonably close to how Matz approaches things.
The lesson one learns repeatedly in all of this is: trust Matz -- he's
good at this! :-)


David

-- 
David A. Black
dblack / wobblini.net