It takes an incredible human to do something like this. Pure art. Not enough of that in the programming world.
Advent of Code 2024 in pure SQL
51–60 of 110 posts
Re: Advent of Code 2024 in pure SQL
#52A former colleague did the same with most of AoC 2020 a few years ago.
Re: Advent of Code 2024 in pure SQL
#53It takes an incredible human to do something like this. Pure art. Not enough of that in the programming world.
Thomas is the greatest database systems researcher in the world. He is an incredible human.
Re: Advent of Code 2024 in pure SQL
#54Earlier 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.
This sounds awful.
I would do almost any amount of iteration and index tuning to keep the query on a single machine rather than deal with a networked distributed system.
When you get slow queries the real problem is algorithmic complexity and linear workers only can do so much,
Re: Advent of Code 2024 in pure SQL
#55Earlier quoted context omitted.
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.
I’d hazard a guess that quite a few devs have at one point, been lumped with a db where someone pushed too much logic into it. Probably great for the one person who wrote it, and awful for everyone else.
Mystery triggers, unclear or badly managed stored procedures, opaque invariants. It’s not to say that all of these things are bad, but a certain level of DB complexity will naturally set off alarm bells for some devs.
Re: Advent of Code 2024 in pure SQL
#56I found Clickhouse easier to handle than pure SQL for this - as an analytics database it has conveniences like parsing input files with regexp, user defined functions and array functions. It's often possible to treat it more like an array programming language. But I still sometimes couldn't avoid the tuple explosion problem.
https://clickhouse.com/docs/en/integrations/data-formats/tem...
Re: Advent of Code 2024 in pure SQL
#57Earlier quoted context omitted.
Why not? I think the main barrier is the programmers are not comfortable with recursion, rather than a technical limitation.
I’d hazard a guess that quite a few devs have at one point, been lumped with a db where someone pushed too much logic into it. Probably great for the one person who wrote it, and awful for everyone else. Mystery triggers, unclear or badly managed stored procedures, opaque invariants. It’s not to say that all of these things are bad, but a certain level of DB complexity will naturally set off alarm bells for some devs…
One of the most eye opening moments in my junior dev career was when I found a really nifty way to achieve an operation using SQL alone and brought it to our VP (start up, small company size). It wasn’t esoteric, but used some SQL features not well-trodden by web devs. I thought I was the bees knees and this would be a clear demonstration of my sizable brain. He complimented the thought behind it, but immediately vetoed it as too complex for the majority of developers who would have to touch the code down the road. In hindsight he was completely right.
Re: Advent of Code 2024 in pure SQL
#58Slightly related, here's one I saw being solved using Cypher: https://www.linkedin.com/posts/halfterpierre_adventofcode-di...
Re: Advent of Code 2024 in pure SQL
#59Does 'pure SQL' have a specific definition (or reference spec)? The author doesn't mention it, except to say he tested it across Umbra, Postgres, and DuckDB. Even then, some days weren't 'supported by DuckDB due to a missing xor operator'.
Re: Advent of Code 2024 in pure SQL
#60Earlier quoted context omitted.
> 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.
Could you please add some examples? I'm still living in poor man's SQL land