On Sunday, 23 December 2012 at 13:21:16 UTC, Andrei Alexandrescu
wrote:
On 12/23/12 6:44 AM, foobar wrote:
Using an all encompassing "algorithms" module is also
unhelpful as all
code is essentially an algorithm to accomplish some task. This
is akin
to opening a store called - "A store" or perhaps "A place to
sell you
stuff".
That I disagree with a bit. I think it's rather clear that
std.algorithm includes classic, consecrated algorithms the kind
you'll find in a book entitled "Algorithms". By your argument a
book called "Algorithms" would not make sense because it would
need to describe the entire computing world.
So if I'm looking for sort, I'd open "algorithm". If I'm
looking for parsing program options, I wouldn't expect it to be
in the same place.
As a client of said shop, I want a better description if I to
buy at the
shop. Even a general "Clothes shop" is already much better.
For 3rd
party it also often makes sense to have a brand name - e.g we
all know
what "vibe.d" is all about.
Such differentiation is also useful.
Andrei
Does it mean you agree with the rest? :)
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.
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.
