dlang.org Library Reference

[John Colvin]

On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu 
wrote:
> On 12/23/12 9:08 AM, foobar wrote:
>> Regarding std.algorithm, the module isn't called - 'classic, 
>> consecrated
>> algorithms the kind you'll find in a book entitled 
>> "Algorithms"'. It is
>> simply called 'std.algorithm' and there are many, *many* books 
>> on
>> algorithms. Should this module include concurrent algorithms? 
>> Should it
>> include distributed algorithms? Should it include statistic 
>> algorithms?
>> Should it include natural language processing algorithms? 
>> Should it
>> include genetic algorithms? I think it's clear by now that the 
>> name does
>> not convey what you intend it to convey.
>
> Importing std.container doesn't mean all containers conceivable 
> will be there, and so on. Sense and sensibility must always be 
> exercised.
>
>> A much better and more user friendly scheme would be to 
>> classify the
>> algorithms by their *functionality* and not by some undefined 
>> "belongs
>> to classical algorithms books" relation.
>> e.g. "Sorting algorithms", "Set operations", etc.
>> Now, if I want to sort something I know to "shop" at the 
>> "sorting
>> algorithms" outlet and don't need to spend time going over a 
>> potentially
>> infinite list of algorithms.
>
> I like std.algorithm the way it is.
>
>
> Andrei

On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu
wrote:
> On 12/23/12 9:08 AM, foobar wrote:
>> Regarding std.algorithm, the module isn't called - 'classic, 
>> consecrated
>> algorithms the kind you'll find in a book entitled 
>> "Algorithms"'. It is
>> simply called 'std.algorithm' and there are many, *many* books 
>> on
>> algorithms. Should this module include concurrent algorithms? 
>> Should it
>> include distributed algorithms? Should it include statistic 
>> algorithms?
>> Should it include natural language processing algorithms? 
>> Should it
>> include genetic algorithms? I think it's clear by now that the 
>> name does
>> not convey what you intend it to convey.
>
> Importing std.container doesn't mean all containers conceivable 
> will be there, and so on. Sense and sensibility must always be 
> exercised.
>
>> A much better and more user friendly scheme would be to 
>> classify the
>> algorithms by their *functionality* and not by some undefined 
>> "belongs
>> to classical algorithms books" relation.
>> e.g. "Sorting algorithms", "Set operations", etc.
>> Now, if I want to sort something I know to "shop" at the 
>> "sorting
>> algorithms" outlet and don't need to spend time going over a 
>> potentially
>> infinite list of algorithms.
>
> I like std.algorithm the way it is.
>
>
> Andrei

Same here. In my mind it's about generality:

General purpose algorithms (sort, partition etc.) belong in
std.algorithm and more specific algorithms belong in their own
appropriately named modules.