Advent of Code 2019

mipri mipri at
Sat Nov 23 04:38:14 UTC 2019

Hello all,

There's one more week in November, and then Advent of Code'll
start again with Christmas-themed programming puzzles, one
released every midnight US/Eastern, with a second part to each
puzzle unlocked after you complete the first part. You can read
more about it at the website:

It's not that serious (when I recommended it last year, to
another community, I was asked if there's a monetary
prize--there isn't one), but it's fun, and it results in lots of
code that's a lot more interesting to compare across languages
and attempts than much else out there. It's not like benchmarks
where the results matter too much to people who have too much
time to put into their work. With Advent of Code you want to
get the answers quickly and, when harder problems can take hours
to complete, people want to go to sleep or get back to other
affairs before the next day's puzzle unlocks. So you get a lot
of relatively honest code, and you can easily talk about the
entries, with everyone still understanding that there's a time
crunch and therefore an amount of sloppiness to be found.

My favorite part of the contest is the two-part format to the
puzzles. You can often cheat a fast solution to the first part,
and then be forced to drastically change your code (or actually
write code this time around) to complete the second part. Which
can mean, again wildly contrary to benchmarks, that you write
code that's a bit generalized or a bit flexible, as you
anticipate the (as yet unknown) hurdle that will come with the
second part of the puzzle.

As a language D has some advantages for this contest:

1. it has some of the 'whipituppitude' characteristic of
scripting languages. You can craft a solution and try it out
relatively quickly with relatively little boilerplate. If the
problem is literally "add up these numbers", you might rdmd
--eval the solution rather than open an editor at all.

2. it can also be very efficient. The puzzle part-twos can be
"take that loop that completed in 100 iterations and change it
so it takes 100 million iterations.", so if you follow the contest
at or similar places you
might see the occasional lament about some Python performance,
or how much memory some Haskell is needing.

3. it also makes it very convenient to take measures to write
correct code, with contract programming, std.exception.enforce,
and unittest blocks. The puzzles can also be difficult to
understand, and it's often very easy to be foiled by a
microscopic failure to adhere to the spec -- and again, there is
a time crunch.

Incidentally, an advantage D doesn't have for this contest is
that it's not a language that you interact with inside of a
persistent workspace. Which means: if you perform some expensive
computation, and finally get an answer to part 1, and then
discover that part 2 is "what would've been the answer if you'd
stopped *right before* the last step of that computation?" then
in D you'll typically get to run that expensive computation all
over again and you'll lose time.  There aren't many languages
like this though.

I hope I'll see some more D this year. I may be posting mine to
the thread (if there is one) or to the learn forum, since I'm
still learning D myself and hope to use the contest to get a lot
more comfortable with the language.

If anyone does want to get really serious about the contest, you
can get on a streaming platform to review and complete the
puzzles with an audience. People really do this. I haven't
followed any of them, but I've been aware that some of the names
on the public leaderboard are streamers.


More information about the Digitalmars-d mailing list