Algorithms to solve programming contest problems

[Dmitry Olshansky via Digitalmars-d]

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