advent_of_code_ex
advent-of-code
advent_of_code_ex | advent-of-code | |
---|---|---|
2 | 4 | |
0 | 0 | |
- | - | |
7.0 | 9.3 | |
6 months ago | 5 months ago | |
Elixir | C++ | |
- | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
advent_of_code_ex
-
Advent of Code 2023 is nigh
> Test your code as you go. Printing the output of intermediate steps to the console is a great way of catching bugs.
Honestly, just set up whatever you need to be able to write unit tests in your lang of choice. These problems are _so_ amenable to a piecewise approach driven by tests. I'm not like a big TDD advocate or anything, but these problems are great practice for that style of coding - it's just so damn useful to know each of your small pieces of code work.
Parameterized tests are amazing for AoC, because you can get a handful of test cases basically for free from the puzzle description. If your code doesn't work once you've got all the samples working, you either have some weird edge case that you didn't consider, or you've got one of the brute-force killer puzzles.
Even for today's, I wound up with 43 different test cases. The vast majority of those are from the puzzle text, and adding them didn't really make the puzzle take that much longer. (Obviously, if you're optimizing for solve speed, you probably wouldn't bother with this approach, but I'm not).
https://github.com/epiccoleman/advent_of_code_ex/blob/master...
Another thing of note is that every puzzle basically operates on a list of strings, so it's pretty easy to genericize certain parts of the work of solving puzzles. I have a script which generates a module for the solution in my repo, with separate functions for each part that receive the input, and a test file that has tests for part 1 and part 2. The tests read the input file and pass it as a list of strings (lines) to the part_1 and part_2 functions, so that all the boilerplate is already done, and I get to just focus on writing the guts of the part_1 and part_2 functions (which usually get broken down into several other functions, which can also be tested individually).
advent-of-code
-
-❄️- 2023 Day 10 Solutions -❄️-
language c++
-
Advent of Code 2023 is nigh
I did 2016 in Haskell and 2018 in Rust. Haskell was kind of a pain since I had to do a ton of tail recursion. Rust would be a lot easier since it allows you to be imperative when you need to.
And I definitely only used a tiny subset of either language because I wanted to get the solution as quickly as possible.
[1] https://github.com/xdavidliu/advent-of-code/tree/main/2016
-
Why Haskell Is Interesting?
So I came to Haskell from Scheme background, so the tail recursion was actually natural to me. In fact, about a month ago I did 2016 Advent of Code in Haskell, and toward the end, I felt like I was abusing tail recursion [1] to write iterative algorithms like breadth-first-search by essentially "repeatedly consing on to the params of tails calls", as Lispers would probably call it.
The whole I'm wondering if I'm just writing Haskell "with a heavy Scheme accent", since I see others' Haskell code make extensive use of state monads (which I still haven't attempted to understand), and I also found others' using way more of the monadic / applicative operators like "bind", etc than I have.
I found the hard part of Haskell not the iteration, which from tail recursion was completely natural and straightforward, but rather worrying about the efficiency of the "repeatedly consing" part. For things like stacks, the cost is O(1), but for things like Data.Array, I wasn't sure how much shared structure there was; I mean it could totally be copying the entire array every time I "mutate" an element (not really, since it was still sort of "consing" onto the old array and not actually mutating it).
[1] https://github.com/xdavidliu/advent-of-code/blob/main/2016/d...
What are some alternatives?
advent2023 - scribblings at advent of code 2023
kino_aoc - A helper for Advent of Code (a smart cell) for Elixir Livebook
advent-of-code - Advent of Code 2022 solutions
fs_playground - F# Playground
tanenbaum - OCaml Advent of Code starter project
the-power-of-prolog - Introduction to modern Prolog
adventofcode - My Advent of code challenges
AdventOfCode2023
aoc - Solutions to Advent of Code.