Insanity. I wonder how much cleaner it could look in EdgeQL.
Somewhat, depending on what you appreciate in languages. See my other comment in this thread: https://news.ycombinator.com/item?id=42578562
Advent of Code 2024 in pure SQL
41–50 of 110 posts
Re: Advent of Code 2024 in pure SQL
#42Earlier quoted context omitted.
Over the years I have been pushing more and more responsibilities into the RDBMS. I now see things mostly in terms of ETL, SQL and schema. Virtually every conversation I've ever had about the application of technology to the business could be expressed in these terms. Business logic defined as SQL queries can be quite intuitive when the schema is structured well and aligned to the business stakeholders' perspectives.…
> Consider that one wouldn't complain as much about a super fucked up nested query (and resulting SQL syntax woes) if it wasn't necessary to write such a query in the first place. And in "modern" SQL this is solved with CTEs. Use them to unwrap the schema the way you want it first, before implementing the business logic.
this is poor man's SQL to unwrap for business logic. SQL is such more more about everything else and so litte about the trouble with mapping business logic into storage.
Re: Advent of Code 2024 in pure SQL
#43Over 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 cou…
Very true. My manager at one of my first jobs liked to say "get the data model right and everything else will be easy" and that has largely been proven true in my experience (and it even applies if you're not using an RDBMS).
Re: Advent of Code 2024 in pure SQL
#44Long ago I was interviewing for an operations job, and their "leetcode" interview question was to create an invoice report of some fairly large public data-set. Because of the size of the dataset and the way they wanted it sliced and diced, it wasn't just a straightforward set of JOINS, and they clearly wanted you to do some simple SQL queries and then have some code loops that sliced and diced it all.
That wasn't a solution the data scientist in me (which I'm not) was ok with. I ran my high level thoughts about the problem past a data scientist buddy of mine and he said "sounds like you're on the right track", but not being a data scientist it was hard for me to put together a soludion.
I told them that if I was asked in my work capacity to do something like this, I'd probably be reaching for a reporting package like Crystal Reports, but I haven't touched it in ~30 years. "Sure, I get that, just write some code to generate the report".
I had written all the Ansible and related goodies to spin up an instance, get MySQL set up and configured, and figured the "right" solution was there in the SQL arcana. I played with it and played with it, mostly writing off the job because what kind of company judges a sys admin based on building a reporting package? They had set the expectation that the homework should take 2-4 hours, and I chewed on it for longer than that and finally said "thanks but no thanks, this is outside my wheelhouse".
But I kept chewing on the problem. A couple weeks later I had the right set of materialized views and queries and joins that not only solved the problem entirely in SQL, but solved it QUICK.
SQL is amazing, but there are a log of tricks of the trade you've got to have at your fingertips to make it fly. I'm still convinced that a lot of it is just throwing a bunch of things at the wall until something sticks.
Re: Advent of Code 2024 in pure SQL
#45Earlier quoted context omitted.
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.
Funnily, I’m actively working on rewriting a stored procedure which parses an XML snippet as one of its arguments
Luckily it’s not a handwritten XML parser though: https://learn.microsoft.com/en-us/sql/t-sql/functions/openxm...
Re: Advent of Code 2024 in pure SQL
#46I 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?
This is just a guess, but if the OP's reason is similar to mine, DBMSs should be reserved for managing databases and not implementing complex logic.
Re: Advent of Code 2024 in pure SQL
#47I 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.
Thanks for that comment.
I laughed aloud at "It's not as bad as you might think if you know what you are doing."
... because that pretty much describes all human activity :-)
Re: Advent of Code 2024 in pure SQL
#48Earlier quoted context omitted.
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?
This is just a guess, but if the OP's reason is similar to mine, DBMSs should be reserved for managing databases and not implementing complex logic.
Why not? I think the main barrier is the programmers are not comfortable with recursion, rather than a technical limitation.
Re: Advent of Code 2024 in pure SQL
#49I was crazy enough to try this as well this year. It would be an extreme stretch to consider me a SQL expert, but I did make it to Day 14.
I agree with all the points in the post. It's really not that bad. If I had more time to devote to it, I think I could have reasonably completed more.
Here's my writeup, contains a link to the repo if you want to see some of the soutions.
https://github.com/ty-porter/advent-of-code/tree/master/2024...
Re: Advent of Code 2024 in pure SQL
#50I 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.
> Most RDBMSs support recursive CTEs, it feels like writing Prolog with a slightly sadistic syntax.
Which makes sense as both are declarative logic-based languages. IMHO, SQL and Prolog fundamentally have much in common.