haha I couldn't help but silently mouth "BUT WHHYY" before I clicked this link
Advent of Code 2024 in pure SQL
31–40 of 110 posts
Re: Advent of Code 2024 in pure SQL
#32Earlier quoted context omitted.
I feel like it'd be entirely acceptable to load the inputs into tables first and still qualify as pure sql, because string parsing in sql is so blergh
Input in AoC is always well-formed. And you can always use a regexp? Seems like the smallest problem to me. As soon as you get past that recursive one row per line trick in the posted solutions
Obviously it's possible, particularly in this context, but generally speaking I'd rather avoid it.
Re: Advent of Code 2024 in pure SQL
#33I've been slowly working through AoC2024 in Google Sheets. I should really write up what I've been up to.
Re: Advent of Code 2024 in pure SQL
#34Over 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 en…
Prolog is very powerful, if you see what professionals can do with it it's eye opening. Unfortunately, it takes a complete relearning of programming to achieve that proficiency level. And after you reach it, you probably cannot use it in your day job...
Re: Advent of Code 2024 in pure SQL
#35Over 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.
SQL clicked once I read the original paper and it explained it terms of sets.
Re: Advent of Code 2024 in pure SQL
#36Over 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.
Being able to master the theoretical, practical, and skill-based components of designing a good database schema is the absolute truest test of understanding any systems design.
People skip ahead to all kinds of nonsense; but most of software engineering is putting the right data into the right format, and moving it around reliably.
I just did a major refactor of a complex distributed code base. I pretty much only count the work I did on schema re-design as the actual “job”, the rest was many hours of coding, but that’s really just implementation.
There are other ways to define schema than SQL of course, but it’s really the perfect way to learn true systems engineering.
Re: Advent of Code 2024 in pure SQL
#37Doing it in pure SQL is really impressive but I think the real tell-tale sign of peak "cracked engineer energy" is the maintained, decade-old blogspot site. Can't exactly put my finger on it, but really gives off "niche mastery". I don't even know the authors but I'm sure in the right circles a few dudes maintaining a blogspot site called "database architects" for a decade probably don't need an introduction.
[deleted]
Re: Advent of Code 2024 in pure SQL
#38Earlier quoted context omitted.
> Once you stop thinking iteratively and start thinking in set operations it becomes quite natural and powerful. I dunno... I've written a tremendous amount of SQL, and I still have to think imperatively (iteratively) in order to write queries that are actually performant, and to know which indexes need to exist. It would be wonderful if I could just think in terms of set operations, but that tends to result in queri…
It may be true, until you do your ETL in an index-less database such as BigQuery or Trino. Postgres will always be faster for optimized, end user serving, queries. But BigQuery allows you to scale it to 100s of CPUs without having to worry about indexes.
Yes, I'm talking about end user queries. Not reports that take 2 hours to run.
But even with BigQuery, you've still got to worry about partioning and clustering, and yes they've even added indexes now.
The only time you really just get to think in sets, is when performance doesn't matter at all and you don't mind if your query takes hours. Which maybe is your case.
But also -- the issue isn't generally CPU, but rather communications/bandwidth. If you're joining 10 million rows to 10 million rows, the two biggest things that matter are whether those 10 million rows are on the same machine, and whether you're joining on an index. The problem isn't CPU-bound, and more CPU's isn't going to help much.
Re: Advent of Code 2024 in pure SQL
#39I 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.
but why? what would make you react at human ingenuity with shame and desire? is this something about you or something about them in particular? isnt the whole of HN about human ingenuity...?
are we to feel Taco Bell menu about it all, what am I missing?
Re: Advent of Code 2024 in pure SQL
#40Over 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 en…
> Maybe somewhere between SQL and Prolog is the future of programming.
it was, it most probably is