Why Ruby?

Christopher Nicholson-Sauls ibisbasenji at gmail.com
Sun Dec 19 02:14:50 PST 2010


On 12/19/10 01:29, spir wrote:
> On Sat, 18 Dec 2010 18:13:50 -0800
> Walter Bright <newshound2 at digitalmars.com> 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.
> 
> Short, but wrong. I mean conceptually. In-code string representation of code is wrong. I cannot explain why, but something in me refuses that. Seems I'm not the only one.

Maybe it's my history with embedded languages with eval() or eval-like
functions, like the BASIC one you referenced... or maybe it's because my
"D brain" likens this usage to the very thing that's going on behind the
scenes (string mixin), and which has proven to be a very handy feature...

I'm not sure what might be the reason, but: I find it suits me fine.
I'm not boasting or anything like that; I'm just pointing out that the
issues no doubt stem, at least in part, from a difference in individual
programmers' experience.  I'm used to making valuable use of things like
eval() -- which you evidently dislike, and not for invalid reasons.
Ultimately, though, I think this whole matter of D lambdas boils down to
just plain not liking the use of strings as anything other than
self-contained text data snips.

One of those weird languages I'm used to had two different kinds of
string literal... and the second one was actually a list of explicit
character codes, as integers.  You'd be surprised the uses one would
find for this thing -- such as easily writing escape code sequences.  My
point?  Different language, different environment.  When the new
environment is drastically different from what we're used to, even if
only in a few aspects, we shy from it.

At any rate, there's always the MiniD syntax to inspire those who must
seek another way.  This:
	func(\a, b -> a * b)
...is rewritten as:
	func(function(a, b) { return a*b; })

Obviously the backslash would be a potential problem.

--Chris N-S


More information about the Digitalmars-d mailing list