Back to index

Challenges for the Advent of Code or
“How to Bite Off More Than You Can Chew, but not too much”


Humans love challenges.
We want to prove something to our friends, our coworkers, our peers, or even just ourselves.
We want to push ourselves to our limits, maybe even beyond them, and grow into more than what we are.
We want to show the world that we can do something, whatever that may be.
We want to get just a tiny bit closer to the optimal version, to the person we could become.

That’s one reason to do Advent of Code. The other — and much more common — is probably just boredom.
For those unaware: Advent of Code is like an advent calendar where there’s a coding task hidden behind each door. You receive a randomized input (actually a randomly selected one from a precomputed set because they can’t store and solve a new puzzle for every user), and you have to enter your solution on the website. How you get that solution doesn’t matter. That should give you a basic idea. Onto the actual content of this.

Learning From Past Experiences

Last year, I failed the Advent of Code. And not just a little bit. I really mean I failed. I wanted to use it as an opportunity to learn Haskell, so my plan was to implement all 24 tasks in Haskell. This should, in theory, give me enough practice to understand the basics and become at least reasonably comfortable in the language.

Reality was… not quite that.
Not only did I not finish even a single puzzle in Haskell, but it deterred me from even trying to learn any functional language for quite a while (that is, until today and ongoing). I then switched to Nim because reasons, but I didn’t finish all 24 in that either. I ended up skipping ~70% of all days.

What do we learn from that?
Well, for one, we shouldn’t just plan tasks of completely unknown complexity. “It will be alright” is not how you approach software. I’ve done that, and it works more often than it should, but this is really a case where it was just silly. For two, (I know that’s not how english works; don’t @ me) I needed variety. Just picking one language may work for other people and it’s certainly useful if you want to learn that language, but it wasn’t enough to keep me motivated.

Going Forward

So what did I change this year? Simple.

I know that there are people who try “24 days, 24 languages”, but I’m not quite that insane. For me, 8 languages should be enough. I’m giving myself three tickets for each language. It is up to me which language I will use for any given day, as long as I have at least one ticket left for that language.
I’ve created a git repo for this challenge here.
The number of remaining tickets for each language can be tracked in the file.
Edit: looks like there are 25 Days, and I misjudged a few things, so I had to change my plans here on day one. Still keeping this section, just because.
The languages I have chosen are (in alphabetical order):
  1. C
  2. Go
  3. Java
  4. Javascript
  5. Kotlin
  6. Nim
  7. Python
  8. Rust
That puts us at 6 compiled and 2 interpreted languages. Out of these, I would rate myself the most proficient in Python and the least proficient in C. Contrary to popular belief, you can be a software developer without ever having touched C.

I would like to add that I’m not necessarily a fan of all of these, especially Java. However, since I’m currently working on a ~1,000,000 loc Java project as my fulltime job, not including it here just felt wrong.
To show my remorse and to give myself a very early impression of the suffering that this decision will bring with it, I’m typing this paragraph in ed, the default editor. It really is quite the experience. The creativity of the people who wrote it is admirable. You wouldn’t believe how many convenience features you can add to an editor that only displays one line at a time. (Let me also remind you that ed was used before monitors were a thing, so printing lines wasn’t free either.) This is, unironically, a better editor than most modern default editors (referring mostly to Windows Notepad and whatever OS X uses).
Oh, and ed supports regex. Everything is better if it supports regex. But I digress.
Apart from the JVM languages, I’ll write all of the solutions in vim, using only Syntastic and the language’s respective command line compilers. Java is just too verbose to be used without introspection and autocompletion. At least for my taste. vim can be really cool to use, and I love it for most languages, but Java is just not one of them. Still typing this in ed, btw. :^)

If I come across a solution that seems particularly interesting to me, I might share it here, but I doubt that will happen. Let’s see how far I can get this year. Expect a recap of this year’s inevitable failure here around the end of the year.

Edit: after finding out that JS has basically no consistent way of reading files, I removed that from the list. It’s garbage anyway, and I’m not writing node.js. Since all of this doesn’t really work with 25 days either, I’ve also decided to drop two more languages to get me to 5x5.
That left me with C, Go, Kotlin, Python, and Rust. 5 days each.

I thought about including Haskell in this list, but I decided not to repeat history… at least for now