Google Code Jam 2011 Language Usage

[Andrew Wiley]

On Sun, May 8, 2011 at 6:10 AM, Peter Alexander <peter.alexander.au@
gmail.com> wrote:

> The Google Code Jam is a programming competition where you have to solve
> algorithmic problems using whatever programming language you like.
>
> The stats of what programming languages were used in the first round were
> collected:
>
> http://www.go-hero.net/jam/11/languages
>
> Some select figures for languages used to solve the first question:
>
> C++     5032
> Java    2321
> C#      628
> C       532
> Haskell 100
> Clojure 13
> GO      13
> D       5
> Scheme  5
>
> (In previous 3 years, D had between 2-4 entries for the first question, so
> not much change, despite total contestant counts increasing quite
> dramatically)
>
> Generally, I believe people tend to use the language they are most familiar
> with, and for people that know more than one language they will choose the
> one that is most expressive. Stability of implementations could also be an
> issue.
>
> Obviously you can't draw too many conclusions from this alone, but more
> data is always better. Take what you will from it.
>
>
I was one of the D users, although I wasn't really worried about competing.
I just wanted to see how D would compare after doing so many programming
contests in Java.
The main thing that frustrated me was that getting input in D wasn't
anywhere near as straightforward as it is in Java. For the first problem,
I'd do something like this in Java:
Scanner in = new Scanner(System.in);
int numTests = in.nextInt();
for(int test = 0; test < numTests; tests++) { //need the test index for
output
int numSteps = in.nextInt();
for(; numSteps < 0; numSteps--)
char robot = in.nextChar();
int button = in.nextInt();
//solve the problem!
}
//print the output!
}


In D, that looked like this:
string line;
int num;
stdin.readln(line);
formattedRead(line, "%s", &num);
for(int casen = 0; casen < num; casen++) {

...

In a few places, I could have used stdin.readf instead of
readln/formattedRead, but not many because the number of items within a test
is on the same line as the items.
I could have just been missing something, but something that was trivial in
Java became brittle in D because I had to exactly match the whitespace for
things to work. I suppose I could have read a line and used splitter to
split on whitespace, but that would make me have to watch more state and
would wind up looking like this:
string line;
stdin.readln(line);
auto split = split(line);
int num = to!int(split[0]);
split = split[1..$];

...

Actually... now that I'm looking at that, if I wrote a Scanner-like class
based on this, is there any chance it could go into Phobos? Seems like
between split and to, we could get something much less brittle working.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110508/1509bf76/attachment.html>