Last year I had just started learning Rust so used that. That turned out to be a mistake, I was spending most of my time figuring out what the borrow checker was complaining about rather than looking at the actual problems.
Hopefully that's behind me now so I will use Rust again.
> I did not design and implement a programming language for the sole or even primary purpose of leaderboarding on Advent of Code. It just turned out that the programming language I was working on fit the task remarkably well.
-- "betaveros, the guy who won 1st place in Advent of Code every single year since 2019"
Good post, just read it. Just curious, why did you link that site (presumably your own, based on your username?) instead of simply linking Hacker News?
I like the puzzle-solving aspect of it - like doing Sudoku, or Alphaguess - but I don't particularly have the time in my life right now to use AoC to learn a new language. (The last time was approximately 6 years ago, when I was learning Elixir - which was also for work. It was also when my child was young enough that I had spare time after her bedtime, but not so young that she didn't sleep through teh night.)
I'm working on the Enso programming language (https://github.com/enso-org/enso), so I will be trying to solve the challenges in the Enso Analytics tool, as our team has been doing for the last two years.
It's always fun to see how we progressed since the previous challenge, making it more pleasant to work with (and also see where the rough corners still are).
I didn't do it last year, but the years before I used Racket and Common Lisp. I might try Common Lisp again since I really want to rediscover the experience of programming w/ Sly (a fork of SLIME).
I'm also considering trying to solve everything with Z3.
I will this year try to be the "support team" for those that will try to do AoC in https://ryelang.org. At least one person said on X.com that he will use it, so we will see :)
Using Ruby for AoC is a pleasure, for me at least. Standard library is rich and the opposite natures of scripting tool and full fledged language are both present and intertwined.
I've experimented over time with the AoC with different languages, but I've found that it made the actual problem solving a lot more difficult for me.
I've done Rust, Go, Python, and TypeScript, and I've preferred Python and TS because I can just crank out some code and get something going. Rust was actually pretty good too, but Go was a bit more verbose than I wanted for something quick and dirty.
I used Common Lisp as my primary language for 2015-2022 and Python for 2023. I've used a few other languages along the way, in parallel to my main effort: Rust, Ada, Python, C++.
I'll probably just use Python this year, so many things are "baked in" to the language that it's the most straightforward. Only downside really is performance, but if you need high performance compiled code for Advent of Code problems you've generally not solved the problem efficiently.
I used Haskell to solve AoC 2022, and in the midst of it I read lots comparisons to Lisp, which in turn turned me off Lisp. E.g. "why calculating is better than scheming".
I'd suppose this is because I have a strong bias to mathsy looking aesthetics.
Will be doing it in F# this year. Last year I did C#/Rust split until real life took over and they ended up being too similar to each other at solving AoC type of challenges.
F# sounds fun, I’ve been goofing off with Haskell in my spare time and really liking how it handles parsing problems. I’d think F# would be elegant for AOC too
I watched somebody on YouTube solve some AoC problems in Excel, so I’m going to try that this year. Not sure how far I’m going to get, but it’ll be a fun challenge!
I’ve been tempted in that direction too. Or using something like “Forth”. Both strike me as a “solve AoC with an abacus” style approaches, requiring bigger levels of problem understanding.
Yeah I think so, especially 2nd time around. You kind of have to refuse to think about your problem computationally; that’s really important when doing prolog I think, else you’ll end up with functional programming.
I try to think about what the solution of the problem implies , and then test each such interpretation against a prolog program to express it.
Last year I had just started learning Rust so used that. That turned out to be a mistake, I was spending most of my time figuring out what the borrow checker was complaining about rather than looking at the actual problems.
Hopefully that's behind me now so I will use Rust again.
That sounds about right if your aim was to learn the language. I had the same experience with Prolog.
https://github.com/betaveros/noulith
Designing a programming language to speedrun Advent of Code: https://hw.leftium.com/#/item/38255808
> I did not design and implement a programming language for the sole or even primary purpose of leaderboarding on Advent of Code. It just turned out that the programming language I was working on fit the task remarkably well.
-- "betaveros, the guy who won 1st place in Advent of Code every single year since 2019"
Good post, just read it. Just curious, why did you link that site (presumably your own, based on your username?) instead of simply linking Hacker News?
- I find it easier to read (based on https://hackerweb.app/).
- Given hw.leftium.com URL, it simple to find original Hacker News URL.
- Given a Hacker News URL, very unlikely to discover my app.
Python. I want to focus on having fun with the puzzles instead of decrypting unfamiliar syntax errors.
Typescript for me, although I only ever do the first few days. I don't have the time to spend on it after that.
Yep.
I like the puzzle-solving aspect of it - like doing Sudoku, or Alphaguess - but I don't particularly have the time in my life right now to use AoC to learn a new language. (The last time was approximately 6 years ago, when I was learning Elixir - which was also for work. It was also when my child was young enough that I had spare time after her bedtime, but not so young that she didn't sleep through teh night.)
I'm working on the Enso programming language (https://github.com/enso-org/enso), so I will be trying to solve the challenges in the Enso Analytics tool, as our team has been doing for the last two years.
It's always fun to see how we progressed since the previous challenge, making it more pleasant to work with (and also see where the rough corners still are).
I’m ready to give zig another try.
gleam was a lot of fun last year, for those who are gleam curious.
For those who are doing something like protocol hackers, instead of adventure code, ocaml 5+ with effects was super fun
I didn't do it last year, but the years before I used Racket and Common Lisp. I might try Common Lisp again since I really want to rediscover the experience of programming w/ Sly (a fork of SLIME).
I'm also considering trying to solve everything with Z3.
I will this year try to be the "support team" for those that will try to do AoC in https://ryelang.org. At least one person said on X.com that he will use it, so we will see :)
I’ve been wanting to play with Kotlin or Ruby.
Kotlin/Closure are more attractive because of their multi-platform support, but Ruby has RoR, but the code looks cleaner which is nice.
Using Ruby for AoC is a pleasure, for me at least. Standard library is rich and the opposite natures of scripting tool and full fledged language are both present and intertwined.
I've experimented over time with the AoC with different languages, but I've found that it made the actual problem solving a lot more difficult for me.
I've done Rust, Go, Python, and TypeScript, and I've preferred Python and TS because I can just crank out some code and get something going. Rust was actually pretty good too, but Go was a bit more verbose than I wanted for something quick and dirty.
I used Common Lisp as my primary language for 2015-2022 and Python for 2023. I've used a few other languages along the way, in parallel to my main effort: Rust, Ada, Python, C++.
I'll probably just use Python this year, so many things are "baked in" to the language that it's the most straightforward. Only downside really is performance, but if you need high performance compiled code for Advent of Code problems you've generally not solved the problem efficiently.
I used Haskell to solve AoC 2022, and in the midst of it I read lots comparisons to Lisp, which in turn turned me off Lisp. E.g. "why calculating is better than scheming".
I'd suppose this is because I have a strong bias to mathsy looking aesthetics.
Will be doing it in F# this year. Last year I did C#/Rust split until real life took over and they ended up being too similar to each other at solving AoC type of challenges.
F# sounds fun, I’ve been goofing off with Haskell in my spare time and really liking how it handles parsing problems. I’d think F# would be elegant for AOC too
I watched somebody on YouTube solve some AoC problems in Excel, so I’m going to try that this year. Not sure how far I’m going to get, but it’ll be a fun challenge!
I’ve been tempted in that direction too. Or using something like “Forth”. Both strike me as a “solve AoC with an abacus” style approaches, requiring bigger levels of problem understanding.
Python. I like to code in Go, but I find Python the easiest for small things I'll only use once.
I used C to do some of the old ones. That was painful (I was a complete C beginner).
Decided that I'm going for Elixir this year. Did few last years puzzles and the experience was really good.
This year I will go with Nushell.
(Maybe will cheat with making Nushell plugin in Rust).
C# again. I aspire to get back to C++ but this isn’t the year for me.
?? turn <language of choice> into api over prolog ??
Typescript because that's all I know.
BASIC. In memoriam
Julia
math :)
[dead]
Yeah I think so, especially 2nd time around. You kind of have to refuse to think about your problem computationally; that’s really important when doing prolog I think, else you’ll end up with functional programming.
I try to think about what the solution of the problem implies , and then test each such interpretation against a prolog program to express it.
[flagged]