ch-ch-changes

[grauzone]

Walter Bright wrote:
> bearophile wrote:
>> grauzone:
>>> Why did you choose to do it like this? Because it is shorter, or
>>> for performance (avoid delegate call)?
>>
>> I agree with the general points you have made. Alex has used aliases
>> for performance.
>>
>> My dlibs (for D1) use closures, I like them. Extensive benchmarking
>> of mine have shown me they are often fast enough. In the spots of the
>> program where you need max performance I just don't use them, and I
>> use normal D code. The good thing is that such critical spots are
>> often 2-5-20% of the lines of the whole program, so for me improving
>> safety and syntax was a win.
> 
> It is hard to hit just the right tradeoff between performance and 
> simplicity. One motivating issue, however, is we don't want to leave an 
> excuse or desire to go back to C or C++ for performance reasons, even if 
> those reasons are not reality.

But they can always roll their own versions of trivial functions like 
map() and so on. Isn't the point of these standard libraries to provide 
something simple and generic? Of course, you can't make everyone happy, 
but why are the performance freaks the one we need to make happy?

If you need high performance code, you'll probably always write your 
own, and won't trust the standard library. Just like you rewrite 
critical parts of code in assembler, and you don't trust the compiler.

> On the other hand, I really like the string mixin approach, I think it 
> works simply and elegantly for most predicates.

Consider you have this code:

 > map!("a*3")(a)

Now you see that you forgot something! For some reason, you actually 
need to return absolute values! Uh-oh, let's fix that:

 > map!("fabs(a*3)")(a)

Oops, this doesn't work. fabs() isn't available, because the code is 
compiled inside the standard library, and not the module, where the code 
was written. This is confusing and non-intuitive. Even more, you don't 
have _any_ way to access fabs() in this code (except if std.algorithm 
imports std.math). You'll have to rewrite this line of code somehow. 
Maybe turn it into a delegate. But then you lose the performance benefit 
you had before. What to do now? Looks like this simple issue caused more 
work than you thought! And all this even though the predicate is simple 
and trivial!

I don't see how this is simple and elegant. Looks more like a hack. It 
reminds me a bit of C++, where things first look simple, but actually... 
they really aren't.

But I get Don's and Andrei's points. End of discussion, I guess.

By the way: thinking about this, it always comes to my mind that D 
really needs AST macros!