Found it in 2016 and have done it ever since (and in the early days of December 2016 I went back and did the 2015 puzzles I'd missed).
I was one of the 271 people who had all 200 stars (i.e. completed all puzzles) when Eric tweeted out that stat.
Usually takes anything from 5 minutes to an hour do most puzzles, quickly hacked together in perl. Very occasionally there's one that takes longer than that. Sometimes I redo them in different languages (Go to try that out, C to remind me how bare bones the base language is, etc).
I'm in the 200 star club and being rather competitive about 2016-2018. I earned at least some global points for each of those years. I started doing the calendar in 2015 but abandonded it halfway through or so. I think it was only in post-partum sorrow after 2016's AoC I went back and did all of 2015.
Very much looking forward to this year's edition and am on several leaderboards.
I warmly recommend this presentation Eric gave in a conference in Sweden a little while back:
Outside of family, work, and exercise, I have time and energy for approximately one personal project.
AoC got to be a bit of a grind for me last year. Something came up, and I missed a few days towards the end. I told myself I was going to go back and finish, but I never did.
I'm tempted to try again this year, but I don't know. I already have projects languishing in need of some attention. On the other hand, it's lots of fun.
Same here. I got back to some problems I left open due to other obligations but finally quit. Plus there's the "problem" of the timezone: Puzzles start at 6am here. Last year I had some time off between jobs but this time it collides with my usual heading to the train. Unless I am really fast and am able to solve between 6:00 and 6:04 ;-)
Related is the tool of choice. I was and would probably still be using Python with the addition of Numpy which by studying other solutions found out to be quite efficient for the AoC type of combinatorics puzzles. Although I had the intention of learning it I didn't make it over the course of a year.
I think I made it to day 6 last year. But not Past the second challenge. I unfortunately have just a little too much going on to tackle it everyday. Maybe this year will be different.
I'm so excited! I discovered AoC in 2017 and I've participated last year as well. In 2017 I used it as an excuse to practice my JavaScript chops using ES2015 classes. Last year I learned me some Rust while doing the problems, at least up until I had to implement a doubly linked list and gave up on using Rust for the rest of the problems.
Hopefully this year I can make it past day 14. It's strange, but I got stuck or tired on day 15 both years. We'll see how it goes, I'm planning on learning Clojure this year with AoC. I've only started learning the language a bit these past 2 weeks, but I'm sure I'll have fun with it.
To all participants this year: remember to have fun!
In my opinion, the thing that makes these puzzles different from bog-standard code challenge sites is simple, but profound: 'the twist'.
Each day's puzzle is not one, but two-fold. You first solve the problem you're given, and then the second half is unlocked. /This second half usually incorporates some sort of twist./ That means that you may have to rethink your program, generalize it, find some missing optimization or think your way around the problem as it's given, etc.
In some ways, it feels like what you have to do to a real program: You write what you think is a perfect solution, then discover you need to model the problem more deeply, or refactor it all, or scrap it and start over. It's a flavor of 'puzzle realism' that makes each day a bite-size nugget of a challenge that's genuinely fun to work out.
You're presented with a pretty unique, bite-size programming challenge every day. Everything is themed around Christmas so there's a short story about how you have to help Santa's elves fix their machinery or something like that.
Different people get slightly different problems, so you have to do your own work to solve for your puzzle input. You feed it back into the site to see if it was correct or not. Getting a problem right was a great feeling, and it progressively unlocks more of a Christmas-themed ASCII art picture.
I would have a tough time explaining it to someone who doesn't do any programming, but it's free to try if you're curious!
It’s a neatly polished programming challenge site which is both communal and competitive, there’s a bonus score (I think) for completing on the same day a challenge is released, there’s a leaderboard race for the first 100 answers each day (typically all gone within 1-2 minutes after midnight) and there’s a subreddit where people share their solutions in all kinds of languages, and it’s nothing to do with competing for a FAANG job interview.
But apart from that it is “just” coding challenges with a story wrapped around them, and if you don’t like those, you won’t care for it.
and see on the sidebar on the right in desktop view, the "Solution Megathreads" e.g. from Day 5 last year there is https://www.reddit.com/r/adventofcode/comments/a3912m/2018_d... with tons of solutions including more oddball ones like VimScript, less popular like Common Lisp and APL, and lots of people use it as an excuse to learn/use a new language, so plenty of Python, Kotlin, Rust, C#, GoLang, D, and so on.
As the days go on, the challenge difficulty increases quite a lot (not linearly) so the threads often turn to discussions about performance, mini-competitions between people, tips on complexity, different approaches and debugging, etc.
The subreddit is pretty great. Tons of good discussion, feedback in the (very rare) cases when something's pear-shaped about the day's puzzle, and a helpful vibe.
I'm beginner programmer and even the early puzzles seem very hard, but after some thought you get correct answers and then you can check from youtube how real programmers do it.
problems are quite interesting (after initial days, those are usually trivial)
e.g. once in 2017 you had problem1: implement an interpreter for this asm-like language. ok, 5 instructions, super easy.
...problem2, run this asm-like program. You couldn't, it was 10^n iterations, would take days. You had to read, understand and optimize the asm-like code.
last year I was amazed writing a function to check if two rectangles intersect (you can do it in like 2 lines)
so, TLDR, you get a lot of "hey that's cool! I never thought about it"
Do you still need to sign up in order to use this? I've been wanting to do AoC for the past few years, but the mandatory signup prevented me from doing so.
Just give me the tasks. I don't want any leaderboards or anything like that.
Edit:
The aspect of customized tasks does not require sign-ups. Just use a cookie or something.
You can login with Reddit or with Github, and Reddit doesn't need an email address, so if you can make a HN account here to rant with, you can make an account for AoC ??
Someone downloads their input, clears their cookies before submitting solution & then their solution is "wrong" because they're using an outdated input.
Seems like tying you to something more persistent i.e. a google/twitter/reddit/github acocunt is a more reliable strategy
Verifying your answer will be tricky though, since you won't know if someone else's code is correct for your input unless you find a repo that also includes the verified result.
Mandatory signups on the internet, especially for tools that don't require them, are dangerous. They feel like deliberate or accidental honeypots, trying to get people's passwords. As members of the industry who have seen the problems that thrive from this practice, we should be opposed to them.
The number of things you need a membership for a extremely limited. Can you imagine if you went to your local supermarket to buy milk, and they said "I'm sorry, you can't buy milk without a membership".
Surely this is one of those cases when a signup is not necessary. Anyone who asks for personal data they do not genuinely require should not be trusted.
As good as AoC is, I think this year I might try and develop the same program (or maybe solve a single one of the puzzles) each day in a different programming language. So one puzzle, 24 languages.. I sorta feel I'd learn more from that rather than sharpening the same knife over and over, perhaps.
For me AoC was perfect while learning a bit of Rust last year, but tread carefully if you want to have 2 mutable references to the same value like a circular or doubly linked list.
I have done it every year, mostly in Rust or C++, with a smattering of other languages (Factor, SML, Haskell). I think I will go with Racket this year.
I'm not competing, partly because I don't want to be up at 6AM, and partly because I like it better as a relaxed 15-30 minutes where I learn some new stuff about the environment I'm working with (for example, one year I used CMake to build, just to get some experience with it).
> I'm not competing, partly because I don't want to be up at 6AM, and partly because I like it better as a relaxed 15-30 minutes where I learn some new stuff about the environment I'm working with (for example, one year I used CMake to build, just to get some experience with it).
Maybe I'm misunderstanding something, but this doesn't seem very exceptional. To me this seems to be 100% within the spirit of the project.
I didn't even know there were competitive aspects in place.
I think the "competition" part stands out because of the nature of competition. But practically it's a supplement for the people who want that. I'm going to wildly guess that the overwhelming majority of participants aren't seriously competing.
I absolutely love and share your approach. Learn new stuff and grow.
This reminds me of SpaceChem, Magnum Opus, or other games like that. I get a solution and then I optimize the solution and explore other methods of getting there.
I tried AoC in Rust two years ago, and you really don't need anything beyond the excellent standard library. Rust has lots of nice features that make working with the type of input AoC gives trivial.
By limiting yourself to the standard library at first, I find that you can get a good feel for the language itself.
You could look up some of the published solutions from last year to get a feel for what is possible.
This person kept a minimal common library for recurring functionality and a small wrapper application that launches the code for each puzzle. It looks like a really clean approach.
I would recommend against a common framework if this is your first venture into rust: I tried exactly this last year, but since I was learning a lot about the language along the way I kept having to go back and update previous days to reflect framework updates.
I tried using it to learn Haskell last year. Warning: it gets hard, and you will want to concentrate on the problem solving, not on compiler errors. It definitely helped my Haskell for the first week or two, but then I switched to Python. I like Rust and recently learned it, but honestly doing AoC in it while learning sounds really painful.
i.e. pass the input from standard input, and just build an on-the-go Vector of some data type that is appropriate for the problem at hand. Day 3 was different from 1 and 2 in that for the first time the parsing was not immediate; using Serde and Recap modules did a fantastically succinct job of parsing the text input. Of course it depends on how much you want to rely on external crates.
Let's see if this year I can do more than 3 days worth of AoC :-)
> This year I really want to try to use this to learn Rust. Are there any good practices or crates to handle file input like most of the problems give?
Last year I asked the same, and I found this answer on SO:
I've been doing the last few years in Clojure (mostly to keep my knowledge of the corelib and the functional paradigm fresh until I can use it in a project). It helps in some problems, and hurts in others - sometimes an imperative, mutable approach is simply the only practical way, and I've fallen back to Java once or twice to do so.
For the simulation-style challenges, I've found the language to be an absolute pleasure, giving some truly lovely code; I'm fairly sure you could make similarly lovely OO code as well, but my tastes find the functional expression of the simulation extremely attractive. Some debugging certainly does get easier, in my opinion.
Last year I did "Advent of Elixir" at my company with the puzzles from AoC. It was slow paced but I got some people excited about Elixir! I also followed José Valim on Twitch to see how he tackled those.
If you want to stay competitive, you've got to invest some time right before Christmas, so I gave up on that pretty quickly. Instead I did the puzzles at my on pace and spent some extra time playing with the puzzles that I found especially fun:
As a bonus, you get something to show whenever you're asked to share some code when applying for a job!
And then there's the learning factor - the puzzles are progressively more difficult, but I guess still doable for the average programmer. At some point some of them start to feel repetitive, but that's great if you get a good hold on processing data in your language of choice.
In general - no. Not in order to solve the problem. But participants familiar with such techniques will often recognize a pattern in a given problem and provide an elegant solution.
I've used it to play with a different language each year, I find the puzzles perfect for that.
This year though, I'm not even starting until January! I find I get completely obsessed with trying to complete them and it can ruin December for (the people around) me ;)
For me it was the ideal way to wade into the rust waters last year, and quickly find out it (rust) was not my cup of tea, at least not at the time. This year I will try to follow along in zig, and see where that takes me.
Mainly high score hunting in Python 3, which is my fastest language. But I also plan to then do every challenge in Perl, which I want to start learning for professional reasons.
Excited as ever for this. Got my toolkit ready. Trying to decide if I want to aim for something besides speed this year; maybe visualizations, or literate code. Given my current work, I probably won't focus on a new language.
This will be my first year. Can you explain what your toolkit is? I don’t have anything prepared and if people are going in with a toolkit it seems like I might not be prepared?
The puzzles are released each day at the same time - 5am UK time (I think it's midnight Eastern Standard Time but don't hold me to that) - and people race for the first correct answers. Check last year's leaderboards and look how fast people answer: https://adventofcode.com/2018/leaderboard/day/1
You don't have to race, it isn't required, but the people who do race are very very quick off the draw - they have scripts which login and download their data file as soon as it's available, then templated code ready to read it in as if it were numbers, as if it were a CSV, and load up some counter variables and arrays to save a few seconds typing, and they skim read ignoring the story, trying to jump to the calculation, code it in moments, run it, get an answer, paste into the site, and verify it. Then download the datafile for part two, skim read the story for part two, modify their code to handle it, run it, get an answer paste that in. First person did both those, all that, in 1 min 48 sec. (!)
Toolkit is mostly "I've done this last year, know what held me up, or what patterns came up several times", you don't need one at all if you're not racing for the first 100 answers.
btw. you can sign up now and do previous year's puzzles if you want to see what it's like.
All of that is very well and I am glad those people find that approach enticing, but I would hate it myself. I participate for the pure joy of solving a puzzle and learning more idiomatic ways of doing that with my language of choice. If that takes me 1 minute, 1 hour, 1 day or 1 week, that's totally fine with me.
Pretty much what others have said. In this case, a language and library I'm comfortable with, and some specific tools for handling the types of input and logic that tend to recur in each year's problems.
Since it's your first year, none of that's needed - just enjoy the puzzles, and search for any useful patterns or tools as you go along. Eric's recommendation is to make the puzzles work for whatever goal you're aiming for - speed isn't necessarily one he recommends, instead recommending it as a tool to learn new languages, or to try new skills, such as visualization.
I use the REPL in the browser dev tools. But when the puzzles get too hard for small pure functions I usually give up and focus on real problems instead :P
I think I am just going to move on one or more of my personal projects forward each day, and tweet about it. just to have a streak ...
i love the idea, i love having a streak to keep you going, but i have a lot of things i want done before i sharpen the saw again - i need wood cut first :-)
Sure. It's just mimicking those traditional advent calendars, counting the days until Christmas with a surprise present or treat for every day to enjoy. Every day, one new puzzle unlocks.
On top, the story that unfolds during December might refer to Santa Claus, and the Easter Bunny, or elves and reindeer. The programming challenges are open for anyone.
I was one of the 271 people who had all 200 stars (i.e. completed all puzzles) when Eric tweeted out that stat.
Usually takes anything from 5 minutes to an hour do most puzzles, quickly hacked together in perl. Very occasionally there's one that takes longer than that. Sometimes I redo them in different languages (Go to try that out, C to remind me how bare bones the base language is, etc).
Can't wait for it to start this year.