26-Oct-2014 04:37, Vic пишет:
On Saturday, 25 October 2014 at 20:51:04 UTC, Walter Bright wrote:
http://www.quora.com/What-are-the-algorithms-required-to-solve-all-problems-using-C++-in-any-competitive-coding-contest
Anyone want to review these and see what we should add to Phobos?
I have enormous respect for Walter, this has me betting my
company on D.
But how I wish this said: hey, anyone know of what we can remove
from D or move to downstream?
Me too. I'd rather see a cleanup of both the language and the library.
More specifically I believe that std lib should do:
1. Set a canonical standard "interface" for 3rd party libraries to model
on - e.g. ranges in large part do that. Same stuff must happen with
exception hierarchy, containers, common OS APIs (Memory, VFS, Networking
etc.) and a whole lot of more minor things. This is a bare minimum that
it must accomplish, it need not have fast implementation but well
thought out & easy interface.
2. Next level - be flexible and define standard for extensibility. That
is to allow 3rd party libraries to _extend_ the standard interface (by
deriving or satisfying similar constraints) rather then re-implement
similar interfaces.
Again very few modules do that currently: std.range, std.algo,
std.digest and maybe one more (upcoming st.logger - might be?). Many,
many traits are too narrow to be useful.
3. Even higher - both interfaces & implementations are pluggable, by
providing common middle ground as a set of primitives. The idea is to
provide a set low-level primitives that any non-std interface may use to
get to re-use standard-compliant "backend", including the default one.
A major example where (3) is useful would be logging that 9 people do in
13 incompatible ways (esp the interface side).
Building on these principles, I should probably fill bugzilla with a
bunch of enhancements.
A couple of examples of missing good standards:
1. std.zip handles ZIP archives with same bizarre interface that
absolutely unlike handling normal file system.
2. DOM-style parsers for XML and JSON are very unlike each other.
JRE has Oracle and 100 devs, CLR has MS and 100 dec, there are 7
for D, and it should be narrow, like LUA.
In all fairness the problem of Orcale is different, they mess with tons
of legacy code in Java they cannot leave behind. So D can sky rocket
with far less dev force (~10-20), especially with the more powerful
language. Problem is our devs are pure enthusiasts with a bit of spare
time to spent.
It should have 7% of
their platform.
We should take the most important 20%, everything else is evolutionary
detritus anyway ;)
> Majority of scared cows must be killed, the
sooner leaders realize the better.
I think now that we have Dub repository, we could just let it grow and
look at the fittest designs to boot the standard from. Maybe start
labeling the most popular as "featured", and have "new" in the same vane.
--
Dmitry Olshansky
