Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advent of Code 2023 is nigh

adventofcode.com

Post reply on HN
Print view View original

121–130 of 319 posts

Re: Advent of Code 2023 is nigh

#121

Post by bo0tzz »

epiccoleman wrote: post #69
bryancoxwell wrote: post #25

I think I’d like to try this year’s in a language I haven’t touched before. What languages should I consider if I want something paradigmatically different from Go, Python, etc?

I do them in Elixir and I find it to be a great language for this kind of thing. I'm not a very sophisticated Elixir programmer, but I think my solutions are decent enough (and readable, for the most part!). I have a repo which has solutions for quite a few of the puzzles, along with some nifty little mix tasks to help set up a skeleton for each day's puzzle and automatically fetch the input file. If you're intereste…

Elixir is great for this, especially with Livebook (https://livebook.dev/) and kino_aoc (https://github.com/ljgago/kino_aoc).

Re: Advent of Code 2023 is nigh

#122

Post by cjauvin »

frantathefranta wrote: post #111
jjice wrote: post #101

Earlier quoted context omitted.

Same here. I would've really like if the spec specifically mentioned the possibility of that one edge case ahead of time instead of having to sift through the 1000 lines of input. No hate on AOC though, I really respect all the hard work that goes into it.

Yeah I was sort of lucky that my edge case was on the last line, still took a full hour of wondering why my solution was wrong though.

I find some problems of AoC are sometimes on the thin line between "it's interesting and I might learn something new" vs "wasting my time with under-specified or ambiguous problem specs".. Part 2 of Day 1 lies dangerously in the latter, for me.

Re: Advent of Code 2023 is nigh

#123

Post by shever73 »

wjholden wrote: post #118
frantathefranta wrote: post #111

Earlier quoted context omitted.

Yeah I was sort of lucky that my edge case was on the last line, still took a full hour of wondering why my solution was wrong though.

What was this edge case you encountered? My code worked...after I finally read the problem closely enough.

For me it was a lack of specific instructions on how to handle overlaps. The edge case that frustrated me for a while was "oneight" at the end of a line. My initial code made it look like this "1ight", when it should have been "18".

Re: Advent of Code 2023 is nigh

#124

Post by Udo »

dataengineer56 wrote: post #4

It's a tough day 1, I hope it doesn't scare off too many people. Normally day 1 is just some variation of "add numbers in a list", but this year has a mean pt 2 and a few traps for people to fall into. I wonder how long the global leaderboard will stay up before it gets hidden due to people solving with ChatGPT?

I'd actually welcome it if the leaderboard was abolished. I never really played for placement, but something about the fact that the board was full of people who routinely solve every problem in about the same time it takes me to even READ the description was a bit demotivating. I always felt this racing aspect to be somewhat at odds with the idea that this is a challenge that you can complete in your own time, maybe even on weekends, and at the end be proud that you even made it.

Re: Advent of Code 2023 is nigh

#125

Post by AdamH12113 »

jjice wrote: post #101
shever73 wrote: post #92

As others have said, part 2 of today's was really difficult. I finally solved it using Python regex `overlapped=true`, but it was very tricky. The irritation of having all of the test cases passing, but it failing for my challenge input! I hope it doesn't scare off newcomers, but I already know a few who have given up on part 2.

Same here. I would've really like if the spec specifically mentioned the possibility of that one edge case ahead of time instead of having to sift through the 1000 lines of input. No hate on AOC though, I really respect all the hard work that goes into it.

Unless the question has been edited recently, it did. There are multiple lines in the second example input that show the overlap:

> eightwothree

> 4nineeightseven2

> zoneight234

I test my AoC solutions incrementally by printing output, so I found that I was failing to produce the correct list of numbers in a line right away. I suppose if you're taking a faster approach and just trying to extract the first and last numbers that it's easier to miss. It's always a good idea to look at the example input, though.

Re: Advent of Code 2023 is nigh

#126

Post by apwell23 »

room500 wrote: post #83
rrishi wrote: post #74

Genuinely curios why people are so into AoC ... Feels leetcode-y

A few reasons I like them: 1. The goal is to come up with a workable solution - not to try to fold your brain inside out to optimize them like leetcode. They feel a little more "real-world" (though still firmly in the domain of programming puzzle) 2. There is a community that all solve them at once. At my company, we have a leaderboard and a Slack channel discussing them every day. And then there is the Reddit and ev…

Same. I use it to connect with ppl at work I would've never interacted with in regular work situations.

Re: Advent of Code 2023 is nigh

#127

Post by j1elo »

burntsushi wrote: post #80
63 wrote: post #76

Day one part 2 was relatively rough. Things I learned from it: rust regex crate doesn't support look-ahead, rust onig crate is currently broken in many ways and shouldn't be used (the version in crates.io doesn't compile and the version on GitHub is failing tests and look-ahead isn't working). It was a very frustrating time for me. After 2 hours of troubleshooting the above I used the same approach in python and it t…

Rust regex crate author here. fancy-regex is built on top of the regex crate and supports look-around. The regex crate doesn't support arbitrary look-around because it isn't known how to implement efficiently. See: https://swtch.com/~rsc/regexp/regexp1.html

> The regex crate doesn't support arbitrary look-around because it isn't known how to implement efficiently.

A bit of a philosophical question:

If how to write an efficient implementation is yet not known to man, ie. not a matter of the library's author time or skills, but literally a limit on human knowledge: why not at least provide the functionality with a good enough implementation? (with caveats just possibly mentioned in documentation)

IMHO that'd be arguably a good thing for everybody, at a minimum better than just not offering the possibility at all. Which drives users to frustration, or leaves them having to discover a more pragmatic alternative lib that opted to add it.

This is no complaint or feature request... I just want to learn from some insight behind the thought process of "if it's not efficient, better not have it at all"

PS. Thanks for the link. Now I have a good read for the weekend, for sure!

Re: Advent of Code 2023 is nigh

#128

Post by tymscar »

AdamH12113 wrote: post #125
jjice wrote: post #101

Earlier quoted context omitted.

Same here. I would've really like if the spec specifically mentioned the possibility of that one edge case ahead of time instead of having to sift through the 1000 lines of input. No hate on AOC though, I really respect all the hard work that goes into it.

Unless the question has been edited recently, it did. There are multiple lines in the second example input that show the overlap: > eightwothree > 4nineeightseven2 > zoneight234 I test my AoC solutions incrementally by printing output, so I found that I was failing to produce the correct list of numbers in a line right away. I suppose if you're taking a faster approach and just trying to extract the first and last nu…

Yes, same. I keep seeing people say this on discord and reddit, but that edge case was shown twice in the example.
Post reply on HN