This year I need to make sure I do the graph search problems properly, because I've never learned those methods and I really should.
I don't know how Eric Wastl manages this each year but I've been participating the last two years and it's ridiculously fun!
I'm guessing this year it might be some other 'common theme' for the tasks, and we might not see as many graph-problems as in 2016.
But learning graph searches cannot hurt you either way :)
Going by hype, I have a feeling learning Rust will some day be as inevitable as interacting with git, but for the moment I'm sticking to D.
It's fast. The D code I write routinely matches or outperforms the C++ I also write for comparison.
D is a much cleaner language. It has obvious C++ inspirations but has thrown out decades of backwards-compatible cruft.
As a result, D has some of C++'s best features, like sophisticated metaprogramming, with much nicer language. In fact, this is the part I like the most: compile-time function evaluation. D allows you to evaluate essentially any function at compile time for which all of its inputs are known at compile time. It almost feels like lisp macros, with the slight downside that they work on unstructured strings instead of (minimally) structured sexps.
D is safe. It produces stack traces when I mess up instead of segfaults. It won't let me compile the most obvious errors it can catch at compile time. I'm not even sure yet if it's possible to have UB in D.
D is flexible. It doesn't impose an opinion on how I should do things. I can do OOP, functional, or procedural as I please and provides useful tools to do all those. OOP is like the familiar classes you know from C++ and Java with interfaces instead of multiple inheritance. Functional programming utilities are useful without being burdensome. You can totally do a for loop in a pure functional function as long as the overall function has no side effects, which is very practical.
D has a bunch of other niceties which you can explore in the D's gems section here:
I'm actually one of the core devs of Nim and so probably naturally your description of D sounds a lot like a description of Nim to me. You should check it out if you haven't already.
I highly recommend participating. AoC is designed as a speed coding competition, but if you aren't playing for the speed points, it's a fun way to learn a new programming language.
That said, it is a fun way to learn a new programming language or to brush up on one you haven't used in a while. Stop by the subreddit and get help if you're having trouble or give some help if you're able!
Get out! Here I was thinking I was the only person using Perl in 2017.
I'm probably going to do this either in a language I'm learning as I go, or in something like Erlang which, whilst great to get correct, will not iterate as fast (for me at least) as the Ruby solution I could quickly and easily write.
I know that I can probably do them in 10 minutes in Python, but that's not going to be as fun or valuable, especially since I'm not going to be able to compete for the leaderboard due to timezone/work.
Then you are in the absolute top tier of the people competing. Either that, or you probably belong in this subreddit https://reddit.com/r/iamverysmart ;)
Having to think about basic things such as how to instantiate hash maps, what is the syntax for control flow, does this language have this particular functionality. This can take hours spent in reading documentation and debugging.
From what I've seen from last year, the problems arent't that hard (they're meant to be solved within a day), so the real time consuming part is the coding.
Couple months ago I discovered Nim , which I find as an interesting language, and I just finished 2015's tasks as a practice .
Now I'm considering using it for this year too. I'll use Python as a fallback, if/when I fail to complete some task in Nim.
The leaderboard is irrelevant, as you can only get on it if you're in the right time zone/nocturnal/unemployed and really really fast, so what you then get out of it is a solid set of Haskell problem-solving skills.
People learn languages in AoC every year. Do it!
Some people do each day in a different language. Maybe don't do that...
However, ICFP is 4 days, not a month, and the experience was good enough that it made me want to actually learn Haskell properly. I had fun and benefited in the long run. :)
Elm served as a gentle intro to Haskell for me personally since it has easier to read errors and less overall complexity to grok at first go, but it sort of depends on your experience.
Would recommend AoC as a learning tool.
I can't recommend this enough. I had to miss out on last year's challenges, but planning on participating this year; it's a great way to keep your brain nimble if you feel like you're in a rut.
There isn't. Some previous tasks could be solved by pen-and-paper, or by using your browser's search on the input, etc.
Also, there were some users who solved each day in a different programming language.
There is also a subreddit (/r/adventofcode) if you get stuck and/or need inspiration. Some really creative solutions there.
Best of luck to everyone this year. See you on the scoreboard! :)