Over my career I've certainly written more SQL than any other type of code. Not so much in the last five years so I'm sure I've lost some of it, but I used to really enjoy it. Once you stop thinking iteratively and start thinking in set operations it becomes quite natural and powerful.
Advent of Code 2024 in pure SQL
11–20 of 110 posts
Re: Advent of Code 2024 in pure SQL
#12The data parsing must have been painful. High wizardry.
Re: Advent of Code 2024 in pure SQL
#13This is impressive. Well done. I hate it
Re: Advent of Code 2024 in pure SQL
#14Insanity. I wonder how much cleaner it could look in EdgeQL.
Re: Advent of Code 2024 in pure SQL
#15Over my career I've certainly written more SQL than any other type of code. Not so much in the last five years so I'm sure I've lost some of it, but I used to really enjoy it. Once you stop thinking iteratively and start thinking in set operations it becomes quite natural and powerful.
I second all of that!
I wish more people would see the beauty. After a session of SQL, when I take a step back and think.
"Hold on. What I have been doing lately is just pure logic. No library dependency resolution, no concurrency problems (even though massive concurrency is certainly under the hood). No mutability issues. Just logic."
SQL obviously has its warts, some of them serious, like testability. But at the end of the day, I wish all programming was like that. Let the computer decide how to do stuff under the hood. And let the human focus on the logic.
I have somewhat half-assed tried to read up on Prolog for trying to take it to the next level, but failed sofar unfortunately. (It was also a goal to try to unlearn some SQL to avoid getting stuck in some local optimum). Maybe somewhere between SQL and Prolog is the future of programming.
Re: Advent of Code 2024 in pure SQL
#16I wrote a cubing/containerization system in SQL, but it did use the additional capabilities in a sproc for looping etc., so not just a single SQL stmt.
But the problem actually mapped well to SQL's capabilities in some ways. The basic algorithm was:
1-Loop through items in descending size order
2-Test X different positions and orientations such that one corner is butted up against an existing corner (of container, or previously placed items, etc.)
3-Choose the winner based on some sort of point systems that encapsulates some set of rules (e.g. preferred orientation, or minimizes small gaps between sides of items, etc.)
These were some aspects that lined up well with SQL:
A-Testing of X number of positions and orientations all with a relative simple statement, using as input: existing corner points from previously placed items, some control table with the variations in X,Y,Z orientations.
B-The ability to maintain a set of previous options for each iteration (e.g. item #2 was tested in these positions with these stats and all are temporarily being considered reasonable options), add new item to each one of those previous tests and accumulate stats. It was pretty easy to configure a "window" of how many different open options were being tracked to optimize the result without overwhelming memory. The SQL to include the options was almost the same as if there was only one previous chosen option.
Some aspects were a bit painful to shift the model mentally to fit in with SQL.
Re: Advent of Code 2024 in pure SQL
#17I reacted to this title the way I react a new menu item at Taco Bell: a strange mixture of desire, shame, and admiration for human ingenuity.
I work a lot with databases and I've seen... stuff. It's not as bad as you might think if you know what you are doing. Most RDBMSs support recursive CTEs, it feels like writing Prolog with a slightly sadistic syntax. For something like AoC the most difficult part is probably parsing the input.
Speaking of parsing, back around y2k we were building an app that used XML everywhere, which was the style at the time, and our DBA wanted to write an xml parser in SQL (the api would involve sending XML to the database). That got vetoed.
IMO, this kind of thing is what AoC is good for - you get to play with weird/obscure stuff without affecting your day job code.
Re: Advent of Code 2024 in pure SQL
#18If you like this kind of degeneracy, I tried AoC in Google Sheets this year.
I only made it to Day 6, and not even both stars every day. I'm pretty confident my Day 7 solution is correct, but I hit per-cell character limits on longer inputs.
Enjoy :) oh but don't open it on mobile, some sheets crash the app
https://docs.google.com/spreadsheets/d/10FY-89y19tnRM_EAAnCd...
Re: Advent of Code 2024 in pure SQL
#19FWIW I tried doing AoC for a few days with EdgeQL, and the experience proved to be quite interesting.
Some of my tweets (I should write a blog post):
Re: Advent of Code 2024 in pure SQL
#20The data parsing must have been painful. High wizardry.
The data parsing is just one recursive query to read one line at a time, and it is done pretty much the same way in each problem.