std.compress

[Max Samukha]

On Wednesday, 5 June 2013 at 06:18:54 UTC, Walter Bright wrote:
> On 6/4/2013 9:44 PM, Max Samukha wrote:
>> On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote:
>>> On 6/4/2013 11:43 AM, Timothee Cour wrote:
>>>> writing generic code.
>>>> same reason as why we prefer:
>>>> auto y=to!double(x) over auto y=to_double(x);
>>>
>>> The situations aren't comparable. The to!double case is 
>>> parameterizing with a
>>> type, the compress one is not. Secondly, compress(lzw) does 
>>> ABSOLUTELY NOTHING
>>> but turn around and call lzw. It adds nothing.
>>
>> That "absolutely" based on limited personal experience is the 
>> biggest D's problem.
>
> I've seen an awful lot of abstractions over the years that 
> provided zero value.

I understand. But I've also seen a lot of abstractions over the 
years that seemed useless initially but were discovered to be 
extremely useful later (Bayes theorem is an example - it took 300 
years to find a concrete use for it). So "a compelling use case" 
is not a sufficient criterion for evaluating usefulness of 
abstractions.

>
> You need to provide a compelling use case to justify another 
> layer of complexity. "generic code" is not a compelling use 
> case. It's already generic.
>
> Note how these components are to be used:
>
>     src.lzwCompress.copy(dst);
>
> Your proposal is:
>
>     src.compress(lzw).copy(dst);
>
> I.e. zero value, as so far all compress() does is call lzw().

That's not my proposal. Honestly I didn't even take a close look 
at it. I just felt like it was time to attack you - there is an 
explicit permission for casual trolling you gave.

>
> The whole point of range-based pipeline programming is you can 
> just plug in different components. There is no demonstrated use 
> case for adding another layer.

Ok.

>
> I am actually wrong in saying it has zero value. It has 
> negative value :-)

In this particular case, maybe.