Many of the comments are about the event as a whole, but I'd like to commend the author for the day 1 puzzle, which I think is very cleverly written. Many people (including myself) use these as an opportunity to try out learning a new language, and the first puzzle does a good job of making sure you know enough basic operations for some of the puzzles coming up. The puzzle itself wasn't very difficult, you could do it by hand if you really wanted to, but it required you to know how to read and parse lines in a file, handle compound data structures, iterate through, and perform basic operations (floor, casting strings to ints, etc). I thought it was really well done, and creates the basic knowledge for the puzzles ahead.
Checking back in - have you done it, is it going OK?
I can't do it when the puzzles come out (too late in UK) but I've really enjoyed Rust so far and I got my 10 stars so far.
Results are really nice, and match and enums etc. really make the language nice.
Rust really has taken many of the best parts of Python, functional paradigms, and lower level languages, and the compiler errors - being warned about missing branches in matches! I'm hoping that finishing 2019 with Rust will lead to more in 2020!
Thanks to these comments, in spite of already having starting advent coding, I have begun learning basic Rust, have the stack and development environment set up and I'm looking forward to doing the first two days again in Rust...
I started last year using Swift Playgrounds. I was lazy and just pasted the input into a multi-line string. I had to switch away from Playgrounds after a couple of days because it would crash due to memory issues. It traces every line of execution and the intermediate values of all variables. I really enjoyed doing the challenges in Swift, but I did have to switch to using my Mac to do it.
This year, I’m learning Python by using a Raspberry Pi 4 directly connected to my iPad via USB. Should be another fun month!
I had to create the plain text input file in iCloud with my Mac then insert it (Big +, third option) in the iPad’s Swift Playground. Need a text app that will save to Files for a complete iPad solution. Also, a Swift Playground bug reverted my final solution to the code from my first few minutes, losing my code. That was frustrating...
Anyway, a complete Swift Playground on iPad solution:
import UIKit
let path = Bundle.main.url(forResource: "input01", withExtension: "txt")
var text = try String(contentsOf: path!, encoding: .utf8)
let massList:[Int] = text.components(separatedBy: .whitespacesAndNewlines).compactMap({Int($0)})
let z1 = massList.map({$0 / 3 - 2}).reduce(0, +)
print("\(z1)")
I couldn't figure it out on a Mac. Then I Googled it, and decided I'm better off solving this in languages I know (whatever I feel like today: JS, Python, Java, perhaps even Erlang) or in a language that has a reasonable standard library (Rust) than in this mess: https://twitter.com/dmitriid/status/1201441652507844608
> The puzzle itself wasn't very difficult, you could do it by hand if you really wanted to, but it required you to know how to read and parse lines in a file, handle compound data structures, iterate through, and perform basic operations (floor, casting strings to ints, etc).
I don't believe that it required any compound data structures, just looping through the lines in the file.
It's faster to just paste the input into your favorite editor, and massage it gently until it is a literal in the language you're using. No parsing necessary.
lol I actually did this typing into source comma down comma down comma... Only after reading this I realized how lazy I was so went back to do it properly. :)
Self promotion, but as this is my first year doing advent of code I'm solving all of the problems using awk[1], the solutions will be published here[2]
Some problems feel like they were designed to be solved in awk, like the assembly style ones. Others, not so much... But it was great fun overall and I learned a lot about awk.
Eric, the author, says he won't accept any puzzle submissions because of attribution and legal issues. This seems like the wrong outcome for people who want to make the site better but don't want credit, compensation, or attribution.
Has anyone seen a site using an IP assignment agreement which is the equivalent of "take my work, I don't want credit, and it's just for your site"?
The Creative Commons CC0 license comes closest, but one could scrape those puzzles and create a competing site, which I'd guess Eric wants to avoid.
It’s a preference in his case that cannot be solved with licensing. Eric doesn’t want even potential ideas to influence him, and he says he has more puzzle ideas than time to implement them.
Personally, I suspect that he wants something that consumes so much of his free time to wholly be his, and I respect that.
If you want to help, why not ask the people running the site what you can do to help? Do you actually want to help, or do you want to make puzzles? Or do you just want to discuss a perceived problem that may or may not exist?
“your site” is really complicated. Who is “you”, person, website or the company? If it’s the person can they transfer the rights? What happens if they die? If they donate the estate? If they get hired or contracted? If the website expands scope or changes in any way?
"You" would be the company, and the submitter would assign all the rights to it. Interestingly, I looked and couldn't find any terms of service or company name.
Maybe he enjoys/benefits from the work, I feel like coming up with puzzle ideas would be somewhat fun/beneficial. I would definitely assume that if this were not the case he would outsource it or maybe even open source it.
I was doing a little of catching up on older problems to improve my speed to get on the leaderboard and I found that the fastest way to finish one problem was to use oeis.
After seeing the problem [0], I didn't immediately think to use oeis because the manhatten distance of a spiral is pretty easy to code or do by hand. The second stage has a harder sequence though. It prompted me to check oeis and I easily got the answer [2] within a minute of checking.
Looking back at the first stage, I found a sequence for it [1] and PARI/GP code i could run to answer the question. If I had used oeis immediately I would have a solution to both phases in 2 minutes which would be the fastest on the old leaderboard for the problem [3].
I had plenty of 20-20 hindsight about faster ways to have solved puzzles in the past. I don't know if I was ever #1 on any day on either star. I think I might've been top 10, on one star, of one day, once.
This event is a really nice way to try out new programming languages. You can easily find many people doing the challenges in various languages and communities coming together to work through the problems together. It’s also very interesting seeing how each person solves the problem in their favourite language.
Always enjoy doing these but there was one last year that nearly broke me. I think it was day15. It was the worst combination of mind-numbing coding and horribly hard to debug special cases. It was purely convoluted with very little to think about which makes for the worst kind of puzzles
I can totally relate about that particular one, I remember that it destroyed a good part of a weekend for me, and I wrote that about it on Twitter, back in January of this year:
"I have thought about the particular challenges of this year's Advent of Code (which I greatly enjoyed once again, with some intermittent mixed feelings), and my conclusion is that some problems might very well be of similar difficulty levels, but with nevertheless very dissimilar frustration-inducing levels. And I think the frustration level is strongly correlated with the feedback signal one can use to debug. Case in point: Day 15, which was almost impossible to debug, once you had a working solution, versus Day 17, which was actually fun to debug, since the visual signal you could use was so strong."
I strongly disliked the puzzles that quickly devolved to correctly handling a ton of corner cases. 15 and 17 were both in this category.
What's the fun in that? This is like the boring part of being a developer. Without the payment that goes with being a developer.
That one wiped me out for a week too, and caused borderline psychological problems.
Ultimately though I realised that if I followed the description word by word, and made no assumptions, then I got the right solution. Still, a nightmare: you could pass all the examples, or even some alternate real sample data, and still get it wrong if you got the ordering slightly incorrect.
Yeah, it's really frustrating when the text summary is vague and underspecified. It makes it hard to understand exactly the result the author is looking for, which isn't the fun kind of puzzle.
I hit day 15 and stopped last year. There always seems to be one puzzle which is so irritating it no longer seems worthwhile when I could be playing some music or building something in Minecraft or just lazing around on the sofa with the cat.
Day 15 was terrible for me too. The edge condition I missed was that you could both move and attack in a single turn. It only changed the outcome for me in part 2. I was only able to finally debug it by comparing debug outputs every step with a known-good solution.
If someone is interested in the previous years of Advent of Code they are available as notebooks in Peter Norvig's pytudes repository: https://github.com/norvig/pytudes
It looks similar to what I though I had to write, but I will have to reread it and the documentation to understand it well.
And day 2 seems a bit too complex with my meager J knowledge. OTOH with the J interpreter for android and its terseness it seems the most suited language for programming on a phone, so I will probably stick to it.
Probably Day 15 [0] from last year. It was challenging, especially because there were so many rules to implement (in a short time). A slight misreading of the rules would let you pass all the provided examples, but fail on the real input.
Idiot-proofing is hard. Figuring out everything people will get wrong is the only reliable way to ensure people don't, but that takes more insight than is needed to set and solve problems correctly.
No doubt. I wasn't really complaining, but that was the one that seemed to cause the most headaches last year. And the text had the problem fully specified, there really was no good way to make it better other than perhaps a different presentation (also a hard problem) or a few extra test cases to tease out those potential misreadings. But you can't catch every error for the participants, coming up with tests is part of the challenge.
It's not really the instructions, but having to implement an obviously imperative ruleset using Elixir. I completed the previous two years using Javascript and Ruby, and it's honestly much easier when you have access to imperative constructs. This year I'm using F#, we'll see how it goes.
I completed the whole thing last year; the problems start out very easy, but get dramatically more challenging over the course of the month. Check out the statistics for how many people completed each problem in 2018: https://adventofcode.com/2018/stats
The first few problems are approachable by pretty much anyone who understands how to do arithmetic, file I/O and basic flow control. Many of the later problems require advanced skills such as more sophisticated algorithms (graph theory, dynamic programming, etc.), reverse engineering, and careful debugging.
For what it's worth, I would expect anyone who knows what a loop is to be able to get the first half of today's problem without much difficulty. The second half is a bit less trivial but also pretty easy to understand.
> Check out the statistics for how many people completed each problem in 2018
I suspect you'd see a dropoff like this regardless of whether the problems get more difficult or not. Going to the gym doesn't get any harder in February but they see the same effect.
If you're medium fast, they start out in the single digit or tens of minutes range and ramp up to some 60+ minute puzzles the last handful of days (but also some 20 minute puzzles, it varies a lot).
I haven't done it since 2017, and I was pretty quick (made that year's overall leaderboard), but on average they took me about 23 minutes (for both parts).
In general the puzzles involve basic operations that any language would have. Functions, data structures, recursion, some amount of back-and-forth between strings and numbers and records. There isn't any reliance on library-like things like making HTTP requests or parsing complex file formats. I think they would be fine for someone starting out at coding.
Every day's puzzle has two parts. The first part is usually easy. The second part is then a twist that requires a change to the solution of the first part.
Apart from that, you can always skip a day if you just can't solve it. The exception is that sometimes a puzzle can reference the solution of an older day, so if you'd solved the older day you would already have an understanding of how to proceed, and might be able to reuse some code.
> I think they would be fine for someone starting out at coding.
The earlier ones, perhaps, but professional programmers struggle with the later ones. I’d never suggest that some one new to programming tries to do all of AoC.
It really helps to (1) have taken an algorithms class and (2) be aware of Python libraries that implement common graph algorithms if you're going for time. At least, that was my impression 2016-2017. The later puzzles are impossible if you don't know a good enough algorithm (they're more or less designed to take impossible amounts of time to completely brute force).
I'd suggest new programmers do any they can reasonably understand and just skip ones that seem like they'll be frustrating or require a "fast" algorithm they don't know. (OTOH, many days' first star can be gotten with a brute force algorithm. It's usually the 2nd star that takes something more clever.)
First couple of tasks are really easy, but difficulty increases over time and so does time needed to solve them.
Someone who is currently learning about loops might not be able to solve these on their own, but with someone else's help they might learn lots of useful concepts (e.g. linked lists, bfs, basic asm, how to code efficiently...) and try to apply them.
AoC are solving usually those who are quite familiar with programming and want to learn a new language or to compete with colleagues.
I wondered the same, also thinking about people I know who are starting to program.
In the end I think it's not a good fit, given that basic concepts are still being understood, and the mere task of reading a file and iterating over the lines, even the concept itself of what "iterating" is, is already a big challenge...
Trying is free and won't hurt, though, so why not :)
For someone just starting out they would get stuck on this very first problem, it involves recursion. People 'get' recursion, but coding it is something different.
Nothing 'needs' recursion, it's always equivalent to an iterative solution. In some languages a recursive solution is more natural and may perform better.
I know of languages that can automatically convert some kinds of recursive code into the iterative equivalent automatically, but I've never seen one that can make the recursive version faster than an iterative equivalent.
Advent of Code is a lot of fun! Last year I wrote a little bit about all the different languages/approaches people use to solve the challenges: https://j11g.com/2018/12/03/advent-of-code/
I went to bed before trying it last night, but couldn't sleep. So I did the day one problem early this morning. It was fun, and went quicker than I thought. I guess I must've improved from last year.
In the first problem they told you what numbers to put in position 1 and 2. In the second problem you want to find the specific numbers for position 1 and 2 that yield the desired output.
In Python 2, floor division is the default for integer arguments and exact (to within machine precision) division the default for floating point arguments, but this caused a lot of unnecessary confusion: new users were surprised that 3.0/2.0 == 1.5, but 3/2 == 1.
Thus for Python 3 the new // operator was added for explicit floor division (which is often quite useful in its own right), leaving the / operator to always return an exact (to machine precision) floating point result, even with integer arguments.
The name is reminiscent of an advent calendar, which traditionally has a labeled door behind which is a piece of candy, small toy or other trinket. These calendars are intended for young children to remind them of the period of advent.
If you are religious, look upon this as a similar thing which reminds you of the season, building in anticipation of the final day.
If you are not religious, it's just a word with no special meaning other than the time of year. Same goes if you are not of a Christian religion.
Because advent is a common term for the 4 weeks before Christmas even in non religious contexts. And that is how it's used in this non religious project.
> if this is a religious project, it should be clearly marked as such.
What an utterly strange proclamation. On every level: the notion that speech should not be free, the notion that users cannot be trusted to figure out what the project is about if it's not "clearly marked" in this way, the notion that there is some harm that can be done by such a "religious project" or a "religious word," whatever that even means.
