7 ms·
Ask HN: How was your Advent of Code 2018 experience?
I really enjoyed this year, the thing that made it quite interesting for me was the amount of people streaming in all kinds of languages with all kinds of approaches.
For me I found it quite a nice learning exercise, though oddly enough ( I was trying to do them as fast as I could ) I often resorted to mega functions and basic data types to solve the problems. This worked out well early in the event, but later it would lead to many simple bugs. I also found that it's nice when your language has a lot of toys to make life easier. I started with Go, as a learning exercise, but swapped to C# as so many problems fit nicely with "Linq", however there were lots of missing niceties, so I spawned a NuGet package with a library of extension methods which I hope to polish now that AoC is over
What are your takeaways?
- minieggs 8y agoFirst few days were great! Fortan was interesting (...) and wow that C++ was not the same beast I used in college. Then uh... kind of got sidetracked.
- hsjoberg 8y agoIt was loads of fun. Decided to try out go, so the first couple of days were a bit slow but from then on it was pure fun. Even though the elves VS goblin game was a bit too much to handle in one single day...
- forrestthewoods 8y agoSuper fun. I’m not caught up yet. Finished day 17 earlier today. I’ve been using the advent to learn Rust. I’m pretty happy with my progress so far. A few things were more difficult than had I used C++. But for the most part it’s gone swimmingly. I love the advent of code subreddit. Every time I solve a puzzle I check how other people did it in Rust. I learned several new things this way.
- tumdum_ 8y agoThis year i wanted to learn Common Lisp (https://git.sr.ht/~ttt/aoc18 https://git.sr.ht/~ttt/aoc18). I think that there had been way to many problems this year that had huge descriptions with many small details to miss. When you add to it huge puzzle state (2d arrays for maps) it makes debugging simple mistakes needlessly hard - in fact solving day 15 for me was almost like working :(
- moomin 8y agoYeah, I’m not a massive fan of the “implement this huge spec” puzzles (like the insanity of the knots last year). Give me a geometric or algorithmic one any day.
- tpaschalis 8y agoI still haven't caught up yet as well as the time zone was not the best for me, but it was a fantastic success. As a mainly Python dev, I tried solving them in Golang during work breaks or afternoons with what little mental energy I had left :P to upload them on Github. I learned so much more about Go, as some puzzles allowed me to use some nifty language features, and really liked the puzzles that featured recursion! In the end of the day, visiting the subreddit, there were tons of ingenious answers, people willing to help, or discuss the problem on a more theoretical basis. I still missed some of Python's minimalistic style, though. Thanks Eric Wastl for this Christmas Gift!
- nemo1618 8y agoI solved all of the problems in Go. I feel like I programmed pretty quickly, but I rarely made it onto the leaderboard. I attribute this to Go's verbosity -- needing to write for loops manually instead of just map/filter/reduce. In 2019 I plan to learn a new language (perhaps Crystal?) that will enable me to solve Advent problems faster.
- IloveHN84 8y agoNever started. No time when you have family+little kid
- fredley 8y agoGreat fun, I was another solving in Go (Python programmer by day). I loved AoC, and learned a lot about Go! The hardest puzzles were definitely the fiddliest ones, day 15 in particular. I wish there was a way for non US people to get a leaderboard in different timezones, appreciate it's hard (impossible) to do fairly.
- cuddlecake 8y agoI used the first few days for learning Elixir. On one day I just did not know how to create a solution at all, so I stopped. Also, I did not have much time, since work and my musicianship were too time consuming. Did not want to come home late in the evening just to lose my mind on more problems that need solving. They might have been easier using an imperative language, but using Elixir had been a joy nonetheless, despite my occasional cravings for indexes and imperative for-loops. But I will definitely come back to AoC to further practice Elixir and watch some of Jose Valim's streams. They always add some further insight into the language.
- zapzupnz 8y agoI'm not ashamed to say I found it too hard and didn't make it beyond day 3, but that's still great. It's a useful way to know what you don't know — although because I couldn't move on to the next puzzle, I still don't know what I don't know. It made me go back to Hackerrank and try a few of those out.
- chrismatheson 8y agoIndeed. I suppose it might make me less of a developer, but I’m not sure I find pure algorithmic work that fun Plus time is always hard to find.
- ahaferburg 8y agoYou can skip days, though. Some are easier than others.
- zapzupnz 8y agoYou can, but some puzzles depend on knowing the solution to another puzzle, or are basically advanced versions of the same thing.
- ahaferburg 8y agoSome do, but most don't. For most puzzles the only dependency is part 2 on part 1.
- moomin 8y agoI’ll tell you in March when I’m finished!
- sfusato 8y agoI've made it up to Day 14 using Elixir after which I got sidetracked, but still followed the Twitch streams from the Elixir community by Jose (Elixir's creator) and James. Fantastic learning experience.
- meheleventyone 8y agoI got up to day 8 before having to give up and start organizing for Christmas. I tried out Zig to do it and you can see my solutions here: https://github.com/meheleventyone/aoc-2018-zig https://github.com/meheleventyone/aoc-2018-zig
- nathan_f77 8y agoIf anyone is interested in programming challenges like this, I've also been working on a programming puzzle. The solution will be a private key worth 0.125 BTC (~$500 USD.) And there will also be a few smaller amounts when solve the intermediate stages. It's going to be posted on my company's blog at 12pm EST on the 30th of December: https://formapi.io/blog https://formapi.io/blog I also did one last year [1], but this time it will be more of a programming challenge instead of a "treasure hunt". Anyway, hope you enjoy it, and good luck! [1] https://formapi.io/blog/posts/bitcoin-treasure-hunt/ https://formapi.io/blog/posts/bitcoin-treasure-hunt/
- tomsmeding 8y agoI actually finished them all, most on the day on which they were published (I had the entire day, since the problems open at 06:00 in my timezone; I didn't try for any leaderboards :p). Some problems took me far too much time (day 15 with its huge simulation!), and overall I agree with the general sentiment that the problems were too finicky, with a lot of details to implement without much real thought. Day 23 part 2 (teleportation nanobots one) was fairly difficult as well; I tried to implement an actual solution, but failed because of wrong assumptions about its correctness. (I tried to represent the intersection of a number of octahedrons with the bounded volume of 8 planes, but it seems that representation is redundant, so there are invalid configurations. I didn't feel like fixing that anymore after 8+ hours.) Looking at the solutions board on reddit, I wrote a smtlib2 script for Z3 that solves it; it works, but isn't all that satisfying. The sheer amount of pathfinding amazed me; some of the plain pathfinding problems were good (day 22 with its pathfinding in the implicit graph where you split nodes up into the various combinations of tools), and I was happy to see that day 25 was just an unordered graph component analysis (i.e. a few floodfills). I liked yesteryear more, and in general I'd like to see smaller problem statements (and thereby also less details to implement!), and possibly slightly more of an algorithmic challenge, though the latter is definitely not necessary (this is not a competitive programming competition, it's an advent calendar of all things!). Still, big thanks to Eric for giving us this! (I did the problems in Rust, to become more familiar with the language. See my implementations here[1].) [1]: https://git.tomsmeding.com/AOC/tree/2018/src https://git.tomsmeding.com/AOC/tree/2018/src
- rst 8y agoFinished them all, and enjoyed it, but Day 23 part 2 (part 1 was trivial) was a real bugbear. In particular, Day 23 was pretty remarkable for the sheer number of "solutions" posted to the solutions board that worked for the person's own input, but only by luck -- they failed for other peoples'. The only possibly general solutions I've seen are the ones that set up external solvers -- either z3 or some integer programming package. (I wound up using the latter, and may have lucked out myself -- whether due to numerical instability or some fault in problem setup, I only got close enough to optimum to find it with a little local hill-climbing.) I'm not sure that's what Eric had in mind; everything else can be solved in Python or Ruby with no recourse to large external libraries. For the most part, I had fun with this stuff -- even day 24, which I had to set aside for hours before a careful desk check found the reason why the answers I was getting weren't quite right. But rules that matter for some people, but not others, do take a bit of the shine off. There were more minor problems along the same lines with some of the other problems -- day 15 and day 24 had a lot of fiddly rules which didn't matter at all for some peoples' inputs.
- chaoxu 8y agoA friend gave me the problem for day 2 part 2, and I found it really cute. Given a set of n strings, each of length m, find if there is a pair that differs in exactly one position. It was not trivial to come up with an optimal and elementary O(nm) time algorithm. (by elementary, I mean something does not need a few hours to implement). I've seen people getting running times of the form O(n^2m), O(n(n+m)) and O(nm^2) on multiple Reddit posts, and was surprised at all kind of different approaches.
- cperciva 8y agoIt was not trivial to come up with an optimal and elementary O(nm) time algorithm. Compute the hashes of the nm strings formed by taking each of the n strings and zeroing out one of the m characters. If you get any hash collisions, compare the strings.
- ahaferburg 8y agoIsn't that O(n∙m²)? for each string (n) for each char (n∙m) zero out char, compute hash (n∙m²)
- pedrosorio 8y agoIf you hand code your own hash function you can compute hash(string with zeroed out i-th character) from hash(string) in O(1) An example of such a hash is a polynomial hash (sum c_i * p^i modulo M, with p and M prime) such as the one used to explain https://en.m.wikipedia.org/wiki/Rabin–Karp_algorithm https://en.m.wikipedia.org/wiki/Rabin–Karp_algorithm
- cperciva 8y agoRight, I meant using a polynomial hash.
- chaoxu 8y agoIndeed, but I want an algorithm with deterministic O(nm) time.
- akanet 8y agoI loved it (and donated to Eric for his amazing work on AoC). I do all the problems in Ruby on CoderPad, and stream it on Twitch. I love stumbling on problems that have incredibly concise solutions in Ruby (day 25 comes to mind) where you end up with roughly 20 lines of code that crunch the whole thing in a few seconds.
- ahaferburg 8y agoI used it as a workout for the compiler that I'm writing. I solved every problem in my own language, so that was pretty cool. The language is now almost as powerful as C. I kept all the code in one file, which now has grown to 4500 LoC (non-empty, non-comment), producing 38k LoC in LLVM. On day 6 I got a stack overflow, so I had to quickly implement new/delete. For the Elf processor I had to add in binary operators. Design-wise it taught me that good literals can be really helpful, e. g. an initializer expression for an array of structs. With Python's dict/tuple/array literals e. g. you could sometimes replace parsing entirely with a couple text transformations in Sublime. Maybe this is specific to these kinds of problems, but I think it would also be helpful for unit tests. It was fun to learn a new algorithm (A*) and implement it. Day 23 part 2 was my favorite. I was stuck for hours, tried two solutions that didn't work out. Went to bed frustrated, then implemented the solution the next morning. I'm still thinking about it, it's an interesting problem.
- Zedronar 8y agoIs there any particular technical reason behind the decision of having 4500 LoC in a single file? It sounds like a pain to maintain and extend.
- ahaferburg 8y agoI wanted to always compile everything, and I don't have modules yet. Every problem is in one function, so for AOC it wasn't a problem.
- tomsmeding 8y agoThat sounds awesome! Do you have any published code for your compiler/language yet? I'm curious :)
- ahaferburg 8y agoThanks! Sorry, I haven't published anything. My inspirations are Jai, Zig, Ante, and Odin, if that helps.
- ElCapitanMarkla 8y agoStopped at day 15 as it was starting to spend too much time on it all :D wouldn't mind picking back up where I left off over my holiday.
- dasmoth 8y agoI've been doing it in Scheme this year, as a major branch of the LISP family I've never tried before. Super-impressed by the speed and solidity of the Chez Scheme implementation, but still a little undecided about how much I like Scheme for day-to-day use. (After Clojure, both Scheme and Common LISP seem to have a fair number of "why is this taking so many keystrokes?" moments). I know a number of people thought some of the "simulation with lots of details to keep track of" problems were a bit over the top this year. Personally, I rather enjoyed them, and in particular found day 15 really satisfying to complete. Not something you'd want to do every day, but it's good to have some problems which pose a bit of a challenge without turning into a "can you pattern-match this against an algorithms textbook" exercise. The overall breadth and balance of problem types was impressive as ever. I hope it's back next year!
- abecedarius 8y ago> why is this taking so many keystrokes? I used to Scheme a lot, and this was a significant part of how Python ended up beating it for regular work. This year I tackled AoC in my own pet new Scheme descendant which tries to fix this problem: https://github.com/darius/squeam https://github.com/darius/squeam -- I'll check in my solutions later today. Incidentally one thing I learned on Day 1 was that Chez Scheme's built-in hash function is not very good. Chez is generally awesome, so maybe it does work well in the context of Chez's built-in hashtable type, or something -- I didn't check. (My Squeam interpreter runs on top of Chez.)
- ashelmire 8y agoDarn, totally forgot about this. December is a hard time for puzzles, too much crunching. Anything like this coming up in the next few months?
- nestorD 8y agoThe good : - I used it as an opportuity to learn Rust and it is definitely a great way to practice with a new language. - I managed to do all but two puzzle within 24h of their publications. - There are some gems (solving the nanobots part2 was very satisfing). The bad : - Some problem took a lot of time because of sentences I found unclear. - Some problems had very long specs (goblin vs elfes). I will probably do it again next year (hoping that rough corners get smoothed).
- pm215 8y agoI took part for the first time this year, as an exercise in learning Rust (I have got up to day 20 so far). It's been pretty good for moving from "I sort of know this language" to being a bit more comfortable with it just by spending more time writing code, and I liked the way the problems get gradually more complicated and tricky. Plus, since each day is a fresh problem you can try different coding approaches without being constrained by having to rewrite a pile of existing code. There are some aspects where things are easier if your language has good support for features which AoC leans on. Notably, almost every problem requires parsing an input text file, so good regex support is really useful. I found myself wishing for a serde regex backend so I could initialize into structs from a regex match without a lot of tedious Point { x: cap[1].parse().unwrap(), y: cap[2].parse().unwrap(), ... } boilerplate. And since a lot of problems use 2D grids of ascii characters, Rust's lack of native 2D arrays and insistence that strings are utf8 and thus not trivially indexable makes things a bit more awkward than they might have been in a different language. I definitely agree with you that a language with a wide ranging standard library helps a lot to make life easier, too.
- TXV 8y agoI found quite frustrating that any non-zero score depends only on time of submission in a specific time zone. It makes it a race and a race for certain people only. But of course one can just take it as an opportunity to practice a language and learn new stuff.
- tofflos 8y agoReally time-consuming and also an eye-opening experience to see how good some of the participants are. I haven't participated before and went into the forums for the first time after having spent 8+ hours coming up with a solution - only to find a video of someone solving the problem in 5 minutes!
- plg 8y agoLove AOC. Finished all puzzles last year and the year before that. Used it as a way to learn Python (coming from C/MATLAB/R). However this year I found the puzzles way too finicky, after about day 5-6. Was taking way too long to load the problem into my head. Perhaps I had greater mental bandwidth in previous years, this year work + growing kids was top of mind. I don’t mind problems that take a long time to think about, and/or take a long time to work through, trial and error, change approaches, etc. What I do mind and what drove me away from AOC this year is that the problems seemed so detailed in ways that seemed arbitrary and ad-hoc, I didn’t have the motivation to spend the time required to load the problem into my head.
- wolco 8y agoWould love to see a list of languages that were tried and successful.
- sonofgod 8y ago"oh I need to implement a circular list" ... reads about collections.deque ... Done.
- Herrin 8y agoFor the most part, I enjoyed it! I was using it to get more familiar with Rust, and I feel a lot more comfortable with the language now. I doubt I did everything idiomatically, and especially not at the beginning, but I feel like I can solve problems now. I've been putting my code on github [1] as I go, if anyone wants to see how I did things. One takeaway for me next year is that there are some common things that pop up on multiple days, and if I actually card about being competitive, I'd want to make generic solutions for them before the competition started. Things like working with 2D and 3D grids, pathfinding, and parsing input. But since I was learning a language, the repetition helped. Another takeaway was that I should not check the problems immediately when they open, which is late for me. Probably about half the time I would tell myself I'd do some simple stuff, then go to bed and finish in the morning. But then I'd get into it, and stay up too late. I do look forward to not having such a messed up sleep schedule next month. I'll definitely be looking forward to it next year. This was my first year, so I may go back and do some past years to fill the time until then. [1] https://github.com/steveherrin/adventofcode2018 https://github.com/steveherrin/adventofcode2018
- cynik_ 8y agoI started in rust but switched over to C (just because I get to apply NIH and have fun writing out things I wouldn't have any reason to otherwise) – currently doing 15; will try to wrap up before the year ends. This is my first time trying and I'm enjoying it a lot.
- justinhj 8y agoLast year I did all problems in Scala, focusing on using pure fp, scalaz and cats. This year I wanted to bolster my Go and Ruby skills since I'm now working on a project that uses both. I found that Ruby was more fun to work with, so much more fun than Go that I only did one solution in Go. Many solutions I found could be solved in an elegant way just as I would have done in Scala or Clojure, but I found some rough edges in Ruby which were partly due to my ignorance of the language and partly because there are some inconsistencies in the collections api. I had to revisit more puzzles for performance improvements than in Scala. For example one puzzle required random access and insert and delete on a very large array which was incredibly slow in Ruby, but would have been acceptable in Scala or Clojure using the Vector collection. Rewriting as a double linked list improved runtime 1000x.
- ofrzeta 8y agoIt was interesting to me. I had to get up early due to the timezone I live in where AoC started at 6am. I didn't really try to make the leaderboard (even less after the first day when I learned how hard it is) but I was in a competitive mode and appropriately nervous. On later days I learned to calm down which also improved my performance. I was using Python which for me turned out to be the optimal programming language for problems like AoC. My reading of other solution on reddit confirms this. You often have to use maps (dictionaries) or lists and Python can be very concise in working with these. Also learned about convenience modules such as "collections" and defaultdict. Some people were able to produce concise and quite readable solutions with Numpy which I want to explore further in the future. Overall I was impressed to see that some people were able to produce short but still very readable Python programs as solutions to the problems. I gave up on day 8 when I didn't have the motivation to cut out the time between (or before) life, work and family to solve more and more complicated puzzles that became more and more arbitrary and didn't show any intrinsic motivation. (Although I did follow on some and found the CPU instruction set puzzle quite interesting).
- volfied 8y agoDay 15 should have been broken down. Or parts of it should have been earlier problems so by the time we got to day 15 it would be a time save to re-use code. I personally try to follow the order of problems, but I'm still on day 15 and with the holidays, kids etc haven't had the mental capacity to sit down and work on it so I doubt I will finish things this year. I don't want to sound ungrateful though, I think the creator is doing an amazing service to software engineers/hobbyists everywhere and it's always fun to see solutions people come up with.
- fred256 8y agoI actually didn't have as much trouble with day 15 as most people seem to have. It took me a while but that was mostly just getting all the finicky details right. Day 23 part 2 I had no idea how to solve correctly and in the end just wrote something that tries a bunch of spread out points, refining around the most promising point. Turned out to give the right answer but could have gotten stuck in a local optimum. I did most of the problems the next day as I didn't want to wait up for the problems to be posted. I did get a few leaderboard positions on days where I did stay up. All in all I enjoyed it, learned a few new things (how A* actually works) and improved my fluency in JavaScript.
- xchaotic 8y agoI've found out about it mid-December from social media contacts looking for hints. I did the first few then life and work got in the way and I am finally catching up to it. I also find that Python is an excellent choice for such ad hoc data explorations
- miguelrochefort 8y ago- I never cared about the stories. I read as little as I need to solve the problems. - I wanted to solve some problems using Prolog, but I struggled and reverted back to C# for all of them. - I used LINQ a lot, including the query syntax which I rarely used before. - I never made it to the leaderboard. I always ranked between 500 and 1000. - I'm constantly surprised by how consistently fast top rankers are. - I'm constantly surprised by how fast time goes by when solving these problems. - I stopped participating at day 14, or when problems started to take me over an hour to solve.