Advent of Code 2016

Thursday, December 29, 2016 :: Tagged under: personal plt engineering projects. ⏰ 3 minutes.

Hey! Thanks for reading! Just a reminder that I wrote this some years ago, and may have much more complicated feelings about this topic than I did when I wrote it. Happy to elaborate, feel free to reach out to me! 😄

A co-worker linked a few of us to Advent of Code, a coding challenge that released a new puzzle every day for December, leading to the 25th.

I participated as best I could, with a twist: try to write every day's solution in a different programming language. I didn't finish (some explanation follows), but I'm proud of my entries. The list of languages is:

Some things left to do:

Did you learn anything new?

Tons! And I'll hopefully blog about those in the future. Here are a few:

You can write Scheme in any language! I learned that the most powerful influence on my general programming style were those library nights with books like The Little Schemer, Structure and Interpretation of Computer Programs, and Programming Languages: Application and Interpretation.

Most of my code:

and jumping between SML, OCaml, Haskell, Racket, Clojure, and even Erlang hardly felt like I was using different languages at all.

Logic programming is a lot more fun than I remember it. I've played with Prolog before, but had an absolute blast using it here. Ditto Mercury.

Wow it's nice working with popular languages. When you have a bug in your Mercury or Factor code, you're a bit SOL. It was refreshing getting to, like, debug again, since you couldn't rely on StackOverflow.


Languages I used for the very first time: Factor, Pyret, OCaml, Elixir, Mercury, Lua.

Languages I've used before technically but only on toy projects, like this: SML, Ruby, Prolog, Common Lisp, Rust, Scala, Clojure.

How did this stack up to other programmer puzzle challenges? For reference, I did about 70 problems on Project Euler back in undergrad. These are a fair bit easier: past the first 15-20 problems, PE tended to rely on you having some kind of mathematical or problem-domain insight to massively reduce the search space. These are far simpler: you can usually just throw the most straightforward algorithm at a problem, and that is usually brute-force.

My other big experience was the old Facebook programming puzzles they'd use for hiring (also described here), which tended to be more algorithmic (graph construction/traversal, clever trees, and dynamic programming were popular in those). Few of these required anything quite like that.

With that

More to come, I hope! 😛

Thanks for the read! Disagreed? Violent agreement!? Feel free to join my mailing list, drop me a line at , or leave a comment below! I'd love to hear from you 😄