
Ask HN: How was your Advent of Code 2018 experience? - keithnz
I really enjoyed this year, the thing that made it quite interesting for me was the amount of people streaming in all kinds of languages with all kinds of approaches.<p>For me I found it quite a nice learning exercise, though oddly enough ( I was trying to do them as fast as I could ) I often resorted to mega functions and basic data types to solve the problems.  This worked out well early in the event, but later it would lead to many simple bugs.  I also found that it&#x27;s nice when your language has a lot of toys to make life easier.  I started with Go, as a learning exercise, but swapped to C# as so many problems fit nicely with &quot;Linq&quot;, however there were lots of missing niceties, so I spawned a NuGet package with a library of extension methods which I hope to polish now that AoC is over<p>What are your takeaways?
======
ahaferburg
I used it as a workout for the compiler that I'm writing. I solved every
problem in my own language, so that was pretty cool. The language is now
almost as powerful as C. I kept all the code in one file, which now has grown
to 4500 LoC (non-empty, non-comment), producing 38k LoC in LLVM.

On day 6 I got a stack overflow, so I had to quickly implement new/delete. For
the Elf processor I had to add in binary operators. Design-wise it taught me
that good literals can be really helpful, e. g. an initializer expression for
an array of structs. With Python's dict/tuple/array literals e. g. you could
sometimes replace parsing entirely with a couple text transformations in
Sublime. Maybe this is specific to these kinds of problems, but I think it
would also be helpful for unit tests.

It was fun to learn a new algorithm (A*) and implement it. Day 23 part 2 was
my favorite. I was stuck for hours, tried two solutions that didn't work out.
Went to bed frustrated, then implemented the solution the next morning. I'm
still thinking about it, it's an interesting problem.

~~~
Zedronar
Is there any particular technical reason behind the decision of having 4500
LoC in a single file? It sounds like a pain to maintain and extend.

~~~
ahaferburg
I wanted to always compile everything, and I don't have modules yet. Every
problem is in one function, so for AOC it wasn't a problem.

------
tomsmeding
I actually finished them all, most on the day on which they were published (I
had the entire day, since the problems open at 06:00 in my timezone; I didn't
try for any leaderboards :p). Some problems took me far too much time (day 15
with its huge simulation!), and overall I agree with the general sentiment
that the problems were too finicky, with a lot of details to implement without
much real thought.

Day 23 part 2 (teleportation nanobots one) was fairly difficult as well; I
tried to implement an actual solution, but failed because of wrong assumptions
about its correctness. (I tried to represent the intersection of a number of
octahedrons with the bounded volume of 8 planes, but it seems that
representation is redundant, so there are invalid configurations. I didn't
feel like fixing that anymore after 8+ hours.) Looking at the solutions board
on reddit, I wrote a smtlib2 script for Z3 that solves it; it works, but isn't
all that satisfying.

The sheer amount of pathfinding amazed me; some of the plain pathfinding
problems were good (day 22 with its pathfinding in the implicit graph where
you split nodes up into the various combinations of tools), and I was happy to
see that day 25 was just an unordered graph component analysis (i.e. a few
floodfills).

I liked yesteryear more, and in general I'd like to see smaller problem
statements (and thereby also less details to implement!), and possibly
slightly more of an algorithmic challenge, though the latter is definitely not
necessary (this is not a competitive programming competition, it's an advent
calendar of all things!).

Still, big thanks to Eric for giving us this!

(I did the problems in Rust, to become more familiar with the language. See my
implementations here[1].)

[1]:
[https://git.tomsmeding.com/AOC/tree/2018/src](https://git.tomsmeding.com/AOC/tree/2018/src)

~~~
rst
Finished them all, and enjoyed it, but Day 23 part 2 (part 1 was trivial) was
a real bugbear.

In particular, Day 23 was pretty remarkable for the sheer number of
"solutions" posted to the solutions board that worked for the person's own
input, but only by luck -- they failed for other peoples'. The only possibly
general solutions I've seen are the ones that set up external solvers --
either z3 or some integer programming package. (I wound up using the latter,
and may have lucked out myself -- whether due to numerical instability or some
fault in problem setup, I only got close enough to optimum to find it with a
little local hill-climbing.) I'm not sure that's what Eric had in mind;
everything else can be solved in Python or Ruby with no recourse to large
external libraries.

For the most part, I had fun with this stuff -- even day 24, which I had to
set aside for hours before a careful desk check found the reason why the
answers I was getting weren't quite right. But rules that matter for some
people, but not others, do take a bit of the shine off. There were more minor
problems along the same lines with some of the other problems -- day 15 and
day 24 had a _lot_ of fiddly rules which didn't matter at all for some
peoples' inputs.

~~~
tomsmeding
> Day 23 [...] I'm not sure that's what Eric had in mind

There is an algorithm for finding a maximum clique in a graph, and some people
on Reddit seem to have used it: the Born-Kerbosch algorithm [1]. Your graph
has a connection between two nodes if their ranges overlap. It relies on the
assumption that overlapping of manhattan regions is transitive; no-one on
Reddit seemed to know whether that assumption is true, and I don't know
either. :)

[1]:
[https://en.wikipedia.org/wiki/Bron%E2%80%93Kerbosch_algorith...](https://en.wikipedia.org/wiki/Bron%E2%80%93Kerbosch_algorithm)

~~~
rst
It's not -- the Reddit thread has a counterexample:

[https://www.reddit.com/r/adventofcode/comments/a8s17l/2018_d...](https://www.reddit.com/r/adventofcode/comments/a8s17l/2018_day_23_solutions/ecdxr1u/)

That said -- one visualization posted elsewhere showed that that person's
particular input was a bunch of singletons, plus one colossal clique that all
intersected at a single point. That may have been structure that people were
meant to discover -- but it's not clear that anyone did until after the fact.
(The person with the visualization identified the clique as all the "bot
ranges" intersecting with a solution point that they'd already found by other
means.)

------
cuddlecake
I used the first few days for learning Elixir.

On one day I just did not know how to create a solution at all, so I stopped.

Also, I did not have much time, since work and my musicianship were too time
consuming. Did not want to come home late in the evening just to lose my mind
on more problems that need solving.

They might have been easier using an imperative language, but using Elixir had
been a joy nonetheless, despite my occasional cravings for indexes and
imperative for-loops.

But I will definitely come back to AoC to further practice Elixir and watch
some of Jose Valim's streams. They always add some further insight into the
language.

------
zapzupnz
I'm not ashamed to say I found it too hard and didn't make it beyond day 3,
but that's still great. It's a useful way to know what you don't know —
although because I couldn't move on to the next puzzle, I still don't know
what I don't know.

It made me go back to Hackerrank and try a few of those out.

~~~
ahaferburg
You can skip days, though. Some are easier than others.

~~~
zapzupnz
You can, but some puzzles depend on knowing the solution to another puzzle, or
are basically advanced versions of the same thing.

~~~
ahaferburg
Some do, but most don't. For most puzzles the only dependency is part 2 on
part 1.

------
volfied
Day 15 should have been broken down. Or parts of it should have been earlier
problems so by the time we got to day 15 it would be a time save to re-use
code. I personally try to follow the order of problems, but I'm still on day
15 and with the holidays, kids etc haven't had the mental capacity to sit down
and work on it so I doubt I will finish things this year.

I don't want to sound ungrateful though, I think the creator is doing an
amazing service to software engineers/hobbyists everywhere and it's always fun
to see solutions people come up with.

------
plg
Love AOC. Finished all puzzles last year and the year before that. Used it as
a way to learn Python (coming from C/MATLAB/R).

However this year I found the puzzles way too finicky, after about day 5-6.
Was taking way too long to load the problem into my head.

Perhaps I had greater mental bandwidth in previous years, this year work +
growing kids was top of mind.

I don’t mind problems that take a long time to think about, and/or take a long
time to work through, trial and error, change approaches, etc.

What I do mind and what drove me away from AOC this year is that the problems
seemed so detailed in ways that seemed arbitrary and ad-hoc, I didn’t have the
motivation to spend the time required to load the problem into my head.

------
tofflos
Really time-consuming and also an eye-opening experience to see how good some
of the participants are. I haven't participated before and went into the
forums for the first time after having spent 8+ hours coming up with a
solution - only to find a video of someone solving the problem in 5 minutes!

------
miguelrochefort
\- I never cared about the stories. I read as little as I need to solve the
problems.

\- I wanted to solve some problems using Prolog, but I struggled and reverted
back to C# for all of them.

\- I used LINQ a lot, including the query syntax which I rarely used before.

\- I never made it to the leaderboard. I always ranked between 500 and 1000.

\- I'm constantly surprised by how consistently fast top rankers are.

\- I'm constantly surprised by how fast time goes by when solving these
problems.

\- I stopped participating at day 14, or when problems started to take me over
an hour to solve.

------
pm215
I took part for the first time this year, as an exercise in learning Rust (I
have got up to day 20 so far). It's been pretty good for moving from "I sort
of know this language" to being a bit more comfortable with it just by
spending more time writing code, and I liked the way the problems get
gradually more complicated and tricky. Plus, since each day is a fresh problem
you can try different coding approaches without being constrained by having to
rewrite a pile of existing code.

There are some aspects where things are easier if your language has good
support for features which AoC leans on. Notably, almost every problem
requires parsing an input text file, so good regex support is really useful. I
found myself wishing for a serde regex backend so I could initialize into
structs from a regex match without a lot of tedious Point { x:
cap[1].parse().unwrap(), y: cap[2].parse().unwrap(), ... } boilerplate. And
since a lot of problems use 2D grids of ascii characters, Rust's lack of
native 2D arrays and insistence that strings are utf8 and thus not trivially
indexable makes things a bit more awkward than they might have been in a
different language. I definitely agree with you that a language with a wide
ranging standard library helps a lot to make life easier, too.

------
moomin
I’ll tell you in March when I’m finished!

------
justinhj
Last year I did all problems in Scala, focusing on using pure fp, scalaz and
cats. This year I wanted to bolster my Go and Ruby skills since I'm now
working on a project that uses both. I found that Ruby was more fun to work
with, so much more fun than Go that I only did one solution in Go. Many
solutions I found could be solved in an elegant way just as I would have done
in Scala or Clojure, but I found some rough edges in Ruby which were partly
due to my ignorance of the language and partly because there are some
inconsistencies in the collections api. I had to revisit more puzzles for
performance improvements than in Scala. For example one puzzle required random
access and insert and delete on a very large array which was incredibly slow
in Ruby, but would have been acceptable in Scala or Clojure using the Vector
collection. Rewriting as a double linked list improved runtime 1000x.

------
nathan_f77
If anyone is interested in programming challenges like this, I've also been
working on a programming puzzle. The solution will be a private key worth
0.125 BTC (~$500 USD.) And there will also be a few smaller amounts when solve
the intermediate stages.

It's going to be posted on my company's blog at 12pm EST on the 30th of
December: [https://formapi.io/blog](https://formapi.io/blog)

I also did one last year [1], but this time it will be more of a programming
challenge instead of a "treasure hunt". Anyway, hope you enjoy it, and good
luck!

[1] [https://formapi.io/blog/posts/bitcoin-treasure-
hunt/](https://formapi.io/blog/posts/bitcoin-treasure-hunt/)

------
sfusato
I've made it up to Day 14 using Elixir after which I got sidetracked, but
still followed the Twitch streams from the Elixir community by Jose (Elixir's
creator) and James.

Fantastic learning experience.

------
Herrin
For the most part, I enjoyed it!

I was using it to get more familiar with Rust, and I feel a lot more
comfortable with the language now. I doubt I did everything idiomatically, and
especially not at the beginning, but I feel like I can solve problems now.
I've been putting my code on github [1] as I go, if anyone wants to see how I
did things.

One takeaway for me next year is that there are some common things that pop up
on multiple days, and if I actually card about being competitive, I'd want to
make generic solutions for them before the competition started. Things like
working with 2D and 3D grids, pathfinding, and parsing input. But since I was
learning a language, the repetition helped.

Another takeaway was that I should not check the problems immediately when
they open, which is late for me. Probably about half the time I would tell
myself I'd do some simple stuff, then go to bed and finish in the morning. But
then I'd get into it, and stay up too late. I do look forward to not having
such a messed up sleep schedule next month.

I'll definitely be looking forward to it next year. This was my first year, so
I may go back and do some past years to fill the time until then.

[1]
[https://github.com/steveherrin/adventofcode2018](https://github.com/steveherrin/adventofcode2018)

------
ofrzeta
It was interesting to me. I had to get up early due to the timezone I live in
where AoC started at 6am. I didn't _really_ try to make the leaderboard (even
less after the first day when I learned how hard it is) but I was in a
competitive mode and appropriately nervous. On later days I learned to calm
down which also improved my performance.

I was using Python which for me turned out to be the optimal programming
language for problems like AoC. My reading of other solution on reddit
confirms this. You often have to use maps (dictionaries) or lists and Python
can be very concise in working with these. Also learned about convenience
modules such as "collections" and defaultdict. Some people were able to
produce concise and quite readable solutions with Numpy which I want to
explore further in the future.

Overall I was impressed to see that some people were able to produce short but
still very readable Python programs as solutions to the problems.

I gave up on day 8 when I didn't have the motivation to cut out the time
between (or before) life, work and family to solve more and more complicated
puzzles that became more and more arbitrary and didn't show any intrinsic
motivation. (Although I did follow on some and found the CPU instruction set
puzzle quite interesting).

------
tumdum_
This year i wanted to learn Common Lisp
([https://git.sr.ht/~ttt/aoc18](https://git.sr.ht/~ttt/aoc18)). I think that
there had been way to many problems this year that had huge descriptions with
many small details to miss. When you add to it huge puzzle state (2d arrays
for maps) it makes debugging simple mistakes needlessly hard - in fact solving
day 15 for me was almost like working :(

~~~
moomin
Yeah, I’m not a massive fan of the “implement this huge spec” puzzles (like
the insanity of the knots last year). Give me a geometric or algorithmic one
any day.

------
ashelmire
Darn, totally forgot about this. December is a hard time for puzzles, too much
crunching. Anything like this coming up in the next few months?

------
dasmoth
I've been doing it in Scheme this year, as a major branch of the LISP family
I've never tried before. Super-impressed by the speed and solidity of the Chez
Scheme implementation, but still a little undecided about how much I like
Scheme for day-to-day use. (After Clojure, both Scheme and Common LISP seem to
have a fair number of "why is this taking so many keystrokes?" moments).

I know a number of people thought some of the "simulation with lots of details
to keep track of" problems were a bit over the top this year. Personally, I
rather enjoyed them, and in particular found day 15 really satisfying to
complete. Not something you'd want to do every day, but it's good to have some
problems which pose a bit of a challenge _without_ turning into a "can you
pattern-match this against an algorithms textbook" exercise. The overall
breadth and balance of problem types was impressive as ever.

I hope it's back next year!

~~~
abecedarius
> why is this taking so many keystrokes?

I used to Scheme a lot, and this was a significant part of how Python ended up
beating it for regular work. This year I tackled AoC in my own pet new Scheme
descendant which tries to fix this problem:
[https://github.com/darius/squeam](https://github.com/darius/squeam) \-- I'll
check in my solutions later today.

Incidentally one thing I learned on Day 1 was that Chez Scheme's built-in hash
function is not very good. Chez is generally awesome, so maybe it does work
well in the context of Chez's built-in hashtable type, or something -- I
didn't check. (My Squeam interpreter runs on top of Chez.)

------
nemo1618
I solved all of the problems in Go. I feel like I programmed pretty quickly,
but I rarely made it onto the leaderboard. I attribute this to Go's verbosity
-- needing to write for loops manually instead of just map/filter/reduce. In
2019 I plan to learn a new language (perhaps Crystal?) that will enable me to
solve Advent problems faster.

------
meheleventyone
I got up to day 8 before having to give up and start organizing for Christmas.
I tried out Zig to do it and you can see my solutions here:

[https://github.com/meheleventyone/aoc-2018-zig](https://github.com/meheleventyone/aoc-2018-zig)

------
fred256
I actually didn't have as much trouble with day 15 as most people seem to
have. It took me a while but that was mostly just getting all the finicky
details right.

Day 23 part 2 I had no idea how to solve correctly and in the end just wrote
something that tries a bunch of spread out points, refining around the most
promising point. Turned out to give the right answer but could have gotten
stuck in a local optimum.

I did most of the problems the next day as I didn't want to wait up for the
problems to be posted. I did get a few leaderboard positions on days where I
did stay up.

All in all I enjoyed it, learned a few new things (how A* actually works) and
improved my fluency in JavaScript.

------
tpaschalis
I still haven't caught up yet as well as the time zone was not the best for
me, but it was a _fantastic_ success.

As a mainly Python dev, I tried solving them in Golang during work breaks or
afternoons with what little mental energy I had left :P to upload them on
Github.

I learned so much more about Go, as some puzzles allowed me to use some nifty
language features, and really liked the puzzles that featured recursion! In
the end of the day, visiting the subreddit, there were tons of ingenious
answers, people willing to help, or discuss the problem on a more theoretical
basis. I still missed some of Python's minimalistic style, though.

Thanks Eric Wastl for this Christmas Gift!

------
hsjoberg
It was loads of fun. Decided to try out go, so the first couple of days were a
bit slow but from then on it was pure fun. Even though the elves VS goblin
game was a bit too much to handle in one single day...

------
chaoxu
A friend gave me the problem for day 2 part 2, and I found it really cute.

Given a set of n strings, each of length m, find if there is a pair that
differs in exactly one position.

It was not trivial to come up with an optimal and elementary O(nm) time
algorithm. (by elementary, I mean something does not need a few hours to
implement).

I've seen people getting running times of the form O(n^2m), O(n(n+m)) and
O(nm^2) on multiple Reddit posts, and was surprised at all kind of different
approaches.

~~~
cperciva
_It was not trivial to come up with an optimal and elementary O(nm) time
algorithm._

Compute the hashes of the _nm_ strings formed by taking each of the _n_
strings and zeroing out one of the _m_ characters. If you get any hash
collisions, compare the strings.

~~~
ahaferburg
Isn't that O(n∙m²)?

    
    
        for each string (n)
          for each char (n∙m)
            zero out char, compute hash (n∙m²)

~~~
pedrosorio
If you hand code your own hash function you can compute hash(string with
zeroed out i-th character) from hash(string) in O(1)

An example of such a hash is a polynomial hash (sum c_i * p^i modulo M, with p
and M prime) such as the one used to explain
[https://en.m.wikipedia.org/wiki/Rabin–Karp_algorithm](https://en.m.wikipedia.org/wiki/Rabin–Karp_algorithm)

~~~
cperciva
Right, I meant using a polynomial hash.

------
nestorD
The good : \- I used it as an opportuity to learn Rust and it is definitely a
great way to practice with a new language. \- I managed to do all but two
puzzle within 24h of their publications. \- There are some gems (solving the
nanobots part2 was very satisfing).

The bad : \- Some problem took a lot of time because of sentences I found
unclear. \- Some problems had very long specs (goblin vs elfes).

I will probably do it again next year (hoping that rough corners get
smoothed).

------
IloveHN84
Never started. No time when you have family+little kid

------
forrestthewoods
Super fun.

I’m not caught up yet. Finished day 17 earlier today.

I’ve been using the advent to learn Rust. I’m pretty happy with my progress so
far. A few things were more difficult than had I used C++. But for the most
part it’s gone swimmingly.

I love the advent of code subreddit. Every time I solve a puzzle I check how
other people did it in Rust. I learned several new things this way.

------
akanet
I loved it (and donated to Eric for his amazing work on AoC). I do all the
problems in Ruby on CoderPad, and stream it on Twitch. I love stumbling on
problems that have incredibly concise solutions in Ruby (day 25 comes to mind)
where you end up with roughly 20 lines of code that crunch the whole thing in
a few seconds.

------
fredley
Great fun, I was another solving in Go (Python programmer by day). I loved
AoC, and learned a lot about Go!

The hardest puzzles were definitely the fiddliest ones, day 15 in particular.

I wish there was a way for non US people to get a leaderboard in different
timezones, appreciate it's hard (impossible) to do fairly.

------
cynik_
I started in rust but switched over to C (just because I get to apply NIH and
have fun writing out things I wouldn't have any reason to otherwise) –
currently doing 15; will try to wrap up before the year ends.

This is my first time trying and I'm enjoying it a lot.

------
TXV
I found quite frustrating that any non-zero score depends only on time of
submission in a specific time zone. It makes it a race and a race for certain
people only. But of course one can just take it as an opportunity to practice
a language and learn new stuff.

------
xchaotic
I've found out about it mid-December from social media contacts looking for
hints.

I did the first few then life and work got in the way and I am finally
catching up to it.

I also find that Python is an excellent choice for such ad hoc data
explorations

------
minieggs
First few days were great! Fortan was interesting (...) and wow that C++ was
not the same beast I used in college. Then uh... kind of got sidetracked.

------
ElCapitanMarkla
Stopped at day 15 as it was starting to spend too much time on it all :D
wouldn't mind picking back up where I left off over my holiday.

------
sonofgod
"oh ____I need to implement a circular list " ... reads about
collections.deque ...

Done.

------
wolco
Would love to see a list of languages that were tried and successful.

