On 13.12.2010 18:39, Nick Sabalausky wrote:
> "Stephan Soller"<stephan.soller@helionweb.de>  wrote in message
> news:ie4srq$138c$1@digitalmars.com...
>> On 12.12.2010 18:01, Simen kjaeraas wrote:
>>>
>>> Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
>>> English. Had foreach used 'in' instead of the semicolon, only
>>> punctuation and 'ln' would be off.
>>>
>>
>> Unfortunately I have to disagree here. If you have well written Ruby code
>> (like Ruby on Rails usually provides) it can usually be read like plain
>> English. That's the reason why I dropped writing documentation comments
>> for Ruby code: it's just redundant.
>>
>
> This common Ruby idiom is totally Yoda-speak to me:
>
>      doSomething unless condition?
>
> The order-of-execution is completely backwards. Plus the "unless" instead of
> "if" makes my mind pause to process an "inverted-context" because *now*
> seeing a "blah" really means "not", and a "!blah" no longer means "not".
>
> Yea, "(action) unless (condition)" is fairly normal English, but code has
> different requirements than normal speech. And besides, it's also perfectly
> normal, easily-understandable English to say "unless (condition), (action)",
> or even a negated if: "if you don't have x, do y". In fact I'd argue the
> English "if you don't have X, do Y" is much easier to understand than "do B
> unless you have C".
>
> With normal English, it's easy enough to hear "do this", and then
> appropriately modify it in your head when you hear it followed by "unless
> that". This is largely because instructions in normal English tend to be
> *much* simpler than instructions in code. With code, there's so many other
> instructions to consider that that extra little mental work of modifying
> something you already processed suddenly makes a difference. But if you see
> something start with the modifier (the condition, in this case) then your
> mind automatically knows it's still an incomplete thought and doesn't do a
> premature "commit". At least that's how my (twisted?) mind works.
>
> Also, Ruby reading like English might be part of why I'm *not* quite won
> over by Ruby's syntax: I'm a native English speaker and I still think
> English makes no sense!
>

I'm not a native English speaker so I can't really judge how much "like English" Ruby really is. However I prefer Rubys pseudo English over some nested function calls with templates or mixins or something like that. Not that code like this is not possible in Ruby but no one actually writes such code with it (or I just haven't seen it).

I avoided "unless" for about a year after learning Ruby. It gave me a headache translating it to "if not" and converting "or"s to "and"s. But over time I fund it useful to write down thoughts without translating them to "if". Maybe "(do something) unless (something)" it's only a common thought pattern in German, don't know how much it is used in English. "unless" is just a small detail and I wouldn't call it a revelation but Ruby has many small details that help you to keep your thoughts more in the problem domain and write code with less "translation" done by the brain. It _feels_ very pleasant over time, sometimes even fun. But I don't think this is something a talk or presentation can convey. One just has to use Ruby for well suited problems for some time.

Happy programming
Stephan Soller

>>
>> I think it's a matter of consistency. In Ruby blocks are used all the
>> time for pretty much everything. In D this isn't the case because
>> usually templates are used for stuff where blocks are used in Ruby (e.g.
>> map, group and find in std.algorithm).
>
> I think that the templates that take a string as a predicate is just an
> ugly hack because D has a too verbose delegate syntax.
>

I absolutely agree with that. However I don't have a better idea how to write it. Delegate syntax is already fairly compact in D.

For example code as this isn't very uncommon in Ruby:

	[1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}

Of course this is a simplified example. Usually the collection would contain some objects and the blocks would filter for a method call (like "e.even?"). However I built a small D1 struct that implements a select and collect function. With the unified function call synatax for array with code should actually work:

	[1, 2, 3, 4, 5].select((int e){ return e > 3; })
		.collect((int e){ return e*e; });

It's already fairly compact. The main overhead is the parameter type and the return statement. I don't believe this can be reduced any more without breaking consistency of the language.

Delegates are way more verbose in other languages like PHP and JavaScript (more or less the same syntax in both languages). Despite that it's no problem to use it and in case of jQuery it's used very often. I think the main reason why delegates are not used like that in D is performance. I'm really not sure about it but I suspect that delegates are less effective than code directly generated by a template like map!(). I don't know how efficient templates can integrate delegates so I just suspect that this is a performance problem.

Happy programming
Stephan Soller

Stephan Soller <stephan.soller@helionweb.de> wrote:

> 	[1, 2, 3, 4, 5].select((int e){ return e > 3; })
> 		.collect((int e){ return e*e; });
>
> It's already fairly compact. The main overhead is the parameter type and the return statement. I don't believe this can be reduced any more without breaking consistency of the language.

The delegates can be passed by alias parameter, and then be written
without the parameter type:

@property void bar(alias t)() {
    t(3);
}

void main() {
    bar!((e){writeln(e);});
}


-- 
Simen

On 2010-12-14 19:33, Stephan Soller wrote:
>>>
>>> I think it's a matter of consistency. In Ruby blocks are used all the
>>> time for pretty much everything. In D this isn't the case because
>>> usually templates are used for stuff where blocks are used in Ruby (e.g.
>>> map, group and find in std.algorithm).
>>
>> I think that the templates that take a string as a predicate is just an
>> ugly hack because D has a too verbose delegate syntax.
>>
>
> I absolutely agree with that. However I don't have a better idea how to
> write it. Delegate syntax is already fairly compact in D.
>
> For example code as this isn't very uncommon in Ruby:
>
> [1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}
>
> Of course this is a simplified example. Usually the collection would
> contain some objects and the blocks would filter for a method call (like
> "e.even?"). However I built a small D1 struct that implements a select
> and collect function. With the unified function call synatax for array
> with code should actually work:
>
> [1, 2, 3, 4, 5].select((int e){ return e > 3; })
> .collect((int e){ return e*e; });
>
> It's already fairly compact. The main overhead is the parameter type and
> the return statement. I don't believe this can be reduced any more
> without breaking consistency of the language.

Probably not, but, for example, Scala allows very compact delegate literals:

Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)

Or more verbose:

Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)

I'm not 100% sure I that the syntax is correct.

> Delegates are way more verbose in other languages like PHP and
> JavaScript (more or less the same syntax in both languages). Despite
> that it's no problem to use it and in case of jQuery it's used very
> often. I think the main reason why delegates are not used like that in D
> is performance. I'm really not sure about it but I suspect that
> delegates are less effective than code directly generated by a template
> like map!(). I don't know how efficient templates can integrate
> delegates so I just suspect that this is a performance problem.
>
> Happy programming
> Stephan Soller

PHP has a very verbose delegate syntax with explicit closures, one of the many reasons I don't use PHP. JavaScript has quite similar syntax as D but the "function" keyword is required, I try to use CoffeeScript (compiles to javascript),  which has a lot nicer delegate syntax, as often I can.

D(dmd) needs to be able to inline delegates.

-- 
/Jacob Carlborg

On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:
> By the way, I couldn't stop cringing at the distasteful, male-centric sexual jokes that the talk is peppered with. Wonder if there was any woman in the audience, and how she might have felt. And this is not a ghetto rant - it's the keynote of a major Ruby conference! (And I'm definitely not a prude.) Am I alone in thinking that this is not what our metier should evolve into?
> 
> 
> Andrei

You're definitely not. No matter how strong pressure is, I stand and fight against common acceptance for female humiliation. It's so sad to me how many think they're real men while treating women as a things they can freely abuse.

Cheers
Piotrek

"Jacob Carlborg" <doob@me.com> wrote in message news:ie8f5f$o6e$1@digitalmars.com...
>
> Probably not, but, for example, Scala allows very compact delegate literals:
>
> Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)
>
> Or more verbose:
>
> Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)
>
> I'm not 100% sure I that the syntax is correct.
>

I'd be surprised if the first one is correct, because that "collect(_ * _)" would seem highly limited (how would you use the same value twice, or use just the second value, or use them in reverse order?).

The second one reminds me of C#'s lambdas and seems like an excellent solution to the question of what to do with all the noise of the extra curly braces, "return" keyword and trailing semicolon. And given that 1. The => isn't currently a valid D token anyway, and 2. The (x) and (x,y) are already being used perfectly fine by the existing delegate literal syntax, I can't imagine there would be any ambiguity with it in D.

I'd be absolutely in favor of adding that to D. In fact, I'd love to see it happen. Just require that the part after "=>" is an expression, accept that the more complex delegates that need statements use the existing syntax (which should be fine since it's only the single-expression-and-nothing-else delegates that are seen as verbose in D), and call it a day.

"piotrek" <starpit@tlen.pl> wrote in message news:ie8fu9$ejl$1@digitalmars.com...
> On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:
>> By the way, I couldn't stop cringing at the distasteful, male-centric sexual jokes that the talk is peppered with. Wonder if there was any woman in the audience, and how she might have felt. And this is not a ghetto rant - it's the keynote of a major Ruby conference! (And I'm definitely not a prude.) Am I alone in thinking that this is not what our metier should evolve into?
>>
>>
>> Andrei
>
> You're definitely not. No matter how strong pressure is, I stand and fight against common acceptance for female humiliation. It's so sad to me how many think they're real men while treating women as a things they can freely abuse.
>

Didja hear the one about the blonde who couldn't find her pencil?

Nick Sabalausky Wrote:

> "piotrek" <starpit@tlen.pl> wrote in message news:ie8fu9$ejl$1@digitalmars.com...
> > On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:
> >> By the way, I couldn't stop cringing at the distasteful, male-centric sexual jokes that the talk is peppered with. Wonder if there was any woman in the audience, and how she might have felt. And this is not a ghetto rant - it's the keynote of a major Ruby conference! (And I'm definitely not a prude.) Am I alone in thinking that this is not what our metier should evolve into?
> >>
> >>
> >> Andrei
> >
> > You're definitely not. No matter how strong pressure is, I stand and fight against common acceptance for female humiliation. It's so sad to me how many think they're real men while treating women as a things they can freely abuse.
> >
> 
> Didja hear the one about the blonde who couldn't find her pencil?

I have a bad sense of humor, but what is this if I'm trolling?

Nick Sabalausky Wrote:

> "Jacob Carlborg" <doob@me.com> wrote in message news:ie8f5f$o6e$1@digitalmars.com...
> >
> > Probably not, but, for example, Scala allows very compact delegate literals:
> >
> > Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)
> >
> > Or more verbose:
> >
> > Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)
> >
> > I'm not 100% sure I that the syntax is correct.
> >
> 
> I'd be surprised if the first one is correct, because that "collect(_ * _)" would seem highly limited (how would you use the same value twice, or use just the second value, or use them in reverse order?).
> 
> The second one reminds me of C#'s lambdas and seems like an excellent solution to the question of what to do with all the noise of the extra curly braces, "return" keyword and trailing semicolon. And given that 1. The => isn't currently a valid D token anyway, and 2. The (x) and (x,y) are already being used perfectly fine by the existing delegate literal syntax, I can't imagine there would be any ambiguity with it in D.
> 
> I'd be absolutely in favor of adding that to D. In fact, I'd love to see it happen. Just require that the part after "=>" is an expression, accept that the more complex delegates that need statements use the existing syntax (which should be fine since it's only the single-expression-and-nothing-else delegates that are seen as verbose in D), and call it a day.

=> would make D look like Perl or PHP or Ruby. Statements are more general than expressions, the D's solution is more general. How much the short new syntax matters if you need two syntaxes for it?! Would mean 2 function syntaxes, 2 delegate syntaxes. Two things was already complex for users.

"lurker" <lurk@lurk.net> wrote in message news:ie8rji$283s$1@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> "Jacob Carlborg" <doob@me.com> wrote in message news:ie8f5f$o6e$1@digitalmars.com...
>> >
>> > Probably not, but, for example, Scala allows very compact delegate literals:
>> >
>> > Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)
>> >
>> > Or more verbose:
>> >
>> > Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)
>> >
>> > I'm not 100% sure I that the syntax is correct.
>> >
>>
>> I'd be surprised if the first one is correct, because that "collect(_ *
>> _)"
>> would seem highly limited (how would you use the same value twice, or use
>> just the second value, or use them in reverse order?).
>>
>> The second one reminds me of C#'s lambdas and seems like an excellent
>> solution to the question of what to do with all the noise of the extra
>> curly
>> braces, "return" keyword and trailing semicolon. And given that 1. The =>
>> isn't currently a valid D token anyway, and 2. The (x) and (x,y) are
>> already
>> being used perfectly fine by the existing delegate literal syntax, I
>> can't
>> imagine there would be any ambiguity with it in D.
>>
>> I'd be absolutely in favor of adding that to D. In fact, I'd love to see
>> it
>> happen. Just require that the part after "=>" is an expression, accept
>> that
>> the more complex delegates that need statements use the existing syntax
>> (which should be fine since it's only the
>> single-expression-and-nothing-else
>> delegates that are seen as verbose in D), and call it a day.
>
> => would make D look like Perl or PHP or Ruby.

If it's added to D, then it would be part of D, and would therefore look like D :)

> Statements are more general than expressions, the D's solution is more general. How much the short new syntax matters if you need two syntaxes for it?! Would mean 2 function syntaxes, 2 delegate syntaxes. Two things was already complex for users.

Not entirely bad points, but C# doesn't seem to have a problem with it. Granted, I'm more in the "provide a variety of tools and let the user choose" camp than the "there is one true answer" one.