D component programming is a joke (Was: Re: Component programming)

[Dejan Lekic]

On Wednesday, 31 July 2013 at 22:23:54 UTC, bearophile wrote:
> Justin Whear:
>
>> If anything, component programming is just functional 
>> programming + templates and some nice syntactic sugar.
>> And a healthy dose of pure awesome.
>
> What D calls "component programming" is very nice and good, but 
> in D it's almost a joke.
>
> Currently this code inlines nothing (the allocations, the 
> difference and the product):
>
>
> import std.numeric: dotProduct;
> int main() {
>     enum N = 50;
>     auto a = new int[N];
>     auto b = new int[N];
>     auto c = new int[N];
>     c[] = a[] - b[];
>     int result = dotProduct(c, c);
>     return result;
> }
>
>
> If you write it in component-style (using doubles here):
>
>
> import std.math;
> import std.algorithm, std.range;
>
> int main() {
>     enum N = 50;
>     alias T = double;
>     auto a = new T[N];
>     auto b = new T[N];
>
>     return cast(int)zip(a, b)
>            .map!(p => (p[0] - p[1]) ^^ 2)
>            .reduce!q{a + b};
> }
>
>
> The situation gets much worse, you see many functions in the 
> binary, that even LDC2 often not able to inline. The GHC 
> Haskell compiler turns similar "components" code in efficient 
> SIMD asm (that uses packed doubles, like double2), it inlines 
> everything, merges the loops, produces a small amount of asm 
> output, and there is no "c" intermediate array. In GHC 
> "component programming" is mature (and Intel is developing an 
> Haskell compiler that is even more optimizing), while in 
> D/dmd/Phobos this stuff is just started. GHC has twenty+ years 
> of head start on this and it shows.
>
> The situation should be improved for D/dmd/Phobos, otherwise 
> such D component programming remains partially a dream, or a 
> toy.
>
> Bye,
> bearophile

I was honestly thinking whether I should reply to this rant or 
not... Obviously I picked the first. - Component programming, as 
you probably know yourself already, is not about making 
super-fast, super-optimized applications, but about making it 
easy both to write the code and to understand the code, as well 
as making it easy to combine components (algorithms mostly) and 
get the result quickly, where by "quickly" I think about time I 
need to write the code.

If you really want a super-optimized solution you will in most 
cases write the piece in question in C. Well, that is at least 
what my experience tells me. Luckily, I do business applications 
most of the time, so performance is rarely an issue. CONVENIENCE 
is! In other words, I shamelessly admit, I only care about the 
time I have to spend coding in order to implement something that 
is of value to the business.