Why Ruby?

[Andrei Alexandrescu]

On 12/19/10 11:31 AM, Ary Borenszweig wrote:
> On 12/19/2010 02:28 PM, Andrei Alexandrescu wrote:
>> On 12/19/10 11:21 AM, foobar wrote:
>>> Andrei Alexandrescu Wrote:
>>>
>>>> On 12/19/10 5:08 AM, foobar wrote:
>>>>> Walter Bright Wrote:
>>>>>
>>>>>> JRM wrote:
>>>>>>> you could write:
>>>>>>> sort!(@1>@2)(x);
>>>>>> [...]
>>>>>>> I think this idea (or something similar) is worth consideration.
>>>>>>> It is
>>>>>>> simply a small extension to an already existing feature that would
>>>>>>> give D
>>>>>>> a terser syntax for lambda's than most of the other languages
>>>>>>> we've been
>>>>>>> discussing.
>>>>>>
>>>>>> but:
>>>>>>
>>>>>> sort!("a>b")(x);
>>>>>>
>>>>>> is just as short! And it already works.
>>>>>
>>>>> I think that the issue here is not about syntax as much as it is
>>>>> about semantics:
>>>>> As others said, this is equivalent to dynamic language's eval() or
>>>>> to D's string mixin and the this raises the question of hygiene
>>>>> which sadly has no good solution in D.
>>>>>
>>>>> The main concern is this:
>>>>> In what context are the symbols 'a' and 'b' evaluated?
>>>>>
>>>>> At the moment they cannot be correctly evaluated at the caller
>>>>> context and do not allow:
>>>>> sort!("a.foo()> b.bar()")(whatever);
>>>>
>>>> That does work. What doesn't work is calling nonmember functions looked
>>>> up in the context of the caller.
>>>>
>>>> Andrei
>>>
>>> Either way, I personally don't care that much for another syntax for
>>> delegates. I personally just want to see this ugly hack removed from
>>> the standard library and discouraged. This feature promotes a code
>>> smell. And for what, as you said yourself, to save 4 characters?
>>
>> "a > b" vs. (a, b) { return a > b; }
>>
>> Savings: 17 characters.
>>
>>> D should be consistent with only ONE delegate syntax. This is why Ruby
>>> reads like poetry to its followers and c++ is like carving letters in
>>> stone.
>>
>> Also, Ruby is well slower than C++ and other languages. It's easy to
>> design a beautiful language if that's the primary concern. It's
>> difficult to design a language when you want to keep in harmony a larger
>> list of desiderata.
>>
>>> I much prefer that the lowering you mentioned to be implemented so
>>> that performance wise this UGLY hack will have no benefits.
>>
>> The lowering will unfortunately solve little. I don't see how
>>
>> sort!"a > b"(array);
>>
>> is horrible but
>>
>> sort(a, b; array) { return a > b; }
>>
>> is beautiful and clear. Besides, that return is bizarre - did you mean
>> return from the comparison or the caller? Ruby chose the latter, which I
>> think is very sensible, but in that case you have a more difficult time
>> returning locally.
>
> Not at all. The last executed statement is what gets returned. And that
> doesn't only apply to blocks, but to normal functions:
>
> def foo
> 1
> end

That would work if and only if it were designed into the language from 
day one - now it's too late. I encourage you to work out through various 
cases (if/else, switch, loops, returning void vs. a value) to see this 
will have considerable difficulties in D.

Andrei