Live data from Hacker News

Advent of Code 2024

adventofcode.com

551–560 of 580 posts

Re: Advent of Code 2024

#551

Earlier quoted context omitted.

Looks pretty neat I'll take some inspiration from this. Though you shouldn't upload the text and inputs of the puzzles (maybe .gitignore them) as per [0]: > Can I copy/redistribute part of Advent of Code? Please don't. Advent of Code is free to use, not free to copy. If you're posting a code repository somewhere, please don't include parts of Advent of Code like the puzzle text or your inputs. If you're making a webs…

I'm usually a rule follower, but this is a rule that I choose not to follow. I have a couple of reasons: - I've spent effort on this, and I want the repository to work in future. I want to be able to clone it and run all the code without having to fetch the input once more, even if the site is unavailable. (I actually do this while benchmarking new hardware). - I don't think it actually hurts the creator in any way,…

I use a private submodule (hosted on my own infra) for the inputs, which addresses point 1. But I get where you're coming from.

Re: Advent of Code 2024

#552

Earlier quoted context omitted.

I'm usually a rule follower, but this is a rule that I choose not to follow. I have a couple of reasons: - I've spent effort on this, and I want the repository to work in future. I want to be able to clone it and run all the code without having to fetch the input once more, even if the site is unavailable. (I actually do this while benchmarking new hardware). - I don't think it actually hurts the creator in any way,…

I use a private submodule (hosted on my own infra) for the inputs, which addresses point 1. But I get where you're coming from.

That's smart! I'll probably do this too when I'll publish my AoC code

Re: Advent of Code 2024

#553
post #208

Earlier quoted context omitted.

One reason I didn't enjoy it was that I felt the days don't build on each other well. So you get little code reuse. It was continually changing requirements, so it was especially like work.

In 2019 he built up about 12 challenges using a VM, for Intcode, you had to construct. It was poorly received because without a working version (developed over the first few Intcode challenges), you couldn't solve the rest of them. He hasn't done anything like that since, though I thought it was probably the more interesting series of challenges. The problem with continuity across days is that the later days can be b…

I can understand that. I think it just points to that the challenge is not for me. It also comes at a time when I desperately want a break or to work on my own projects, software or otherwise.

Re: Advent of Code 2024

#554
I always get too ambitious with AoC, e.g. trying to do it in a new to me language or abstract everything into a new library. Subsequently I never finish. So this year I'm using whatever language or tool is easiest for me and the only goal is to finish!

Re: Advent of Code 2024

#555
post #478

If LLMs are really as good at writing code as some people say, they should write a script that fetches each challenge, as soon as it's released, and feeds it to an LLM, to produce a solution. Then run this code and submit the answer it outputs.

This is how most of the top of leaderboard works.

Do you have any evidence to support that claim? Competitive programmers (especially those with their own libraries ready to go) can be incredibly fast at solving coding challenges.

Re: Advent of Code 2024

#557

This is my fourth year. I'm using Go while being surprised how inadequate it is for this kind of problem. Standard libraries lack basic data structures and often Go is too slow for a compiled language!

What does "Go is too slow" mean in this context? Were you expecting similar performance to Rust or C++?

Well, it is slow to run, because all the built-in Python magic is highly optimized. When you start implementing stuff in the bare bones Go, and you're pressed by time, you don't optimize, and the result is code that is slower than Python.

Re: Advent of Code 2024

#559

This years challenge for me: write it in C without the standard library or an allocator. Has to be runnable on an STM32 with 32kb of SRAM. I tried doing it in Assembly two years ago, ended up spending hours and hours writing an Assembly standard library, then gave up and switched to Rust...

I tried doing it in C a few years ago but wasted so much time just not having a string library

Re: Advent of Code 2024

#560

This years challenge for me: write it in C without the standard library or an allocator. Has to be runnable on an STM32 with 32kb of SRAM. I tried doing it in Assembly two years ago, ended up spending hours and hours writing an Assembly standard library, then gave up and switched to Rust...

Last year I tried C on a real Amiga 1200 (using DICE, Matt Dillon’s compiler / runtime). I didn’t get very far, lack of memory protection makes things really hard. This year the Amiga has an 060 upgrade with an MMU, so perhaps I can figure out how to use that and have another go.

> I didn’t get very far, lack of memory protection makes things really hard

What was the issue with lack of memory protection? If you're used to programming in C is there actually that much difference to running on a modern PC or embedded system?

Post reply on HN