Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advent of Code 2024 in pure SQL

databasearchitects.blogspot.com

Post reply on HN
Print view View original

91–100 of 110 posts

Re: Advent of Code 2024 in pure SQL

#91

Post by arkh »

coliveira wrote: post #34
fifilura wrote: post #15

Earlier quoted context omitted.

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...

My problem with Prolog is every time I want to start using it I feel like I'm populating a database then doing queries on it. So it feels like SQL with another syntax and less power.

I'm sure I'm wrong and missing something but that's where I stop.

Re: Advent of Code 2024 in pure SQL

#92

Post by NDizzle »

phartenfeller wrote: post #75

Nicely done. I know this seems crazy at first but in my opinion big SQLs are one of the best ways to store complexity. The problem being complex is the issue. SQL is a standard, condensed, extremely performant, actually testable, and logical language. Sure, not anybody can instantly maintain it but that would be the same as if it was a lot of lines and functions in Java. The more lines the more risk for bugs. I also…

> in my opinion big SQLs are one of the best ways to store complexity.

Only if, ONLY IF, you have a lot of people that are well versed in SQL. It's very easy to write bad SQL. It's difficult to unravel thousands of lines of bad SQL spread across hundreds of procedures / views / functions. Ask me how I know...

Re: Advent of Code 2024 in pure SQL

#93

Post by diggan »

phartenfeller wrote: post #75

Nicely done. I know this seems crazy at first but in my opinion big SQLs are one of the best ways to store complexity. The problem being complex is the issue. SQL is a standard, condensed, extremely performant, actually testable, and logical language. Sure, not anybody can instantly maintain it but that would be the same as if it was a lot of lines and functions in Java. The more lines the more risk for bugs. I also…

> but in my opinion big SQLs are one of the best ways to store complexity.

It seems crazy at first, and then I continue thinking about it and it still seems crazy for wanting complexity to be in SQL.

Personally, I want anything complex to ideally easily testable, both manually and automatically. SQLs is easy to test manually, but harder to test automatically, especially compared to lines of code in a programming language. At least you can somewhat untangle balls of spaghetti code into less dense, then attack parts of it. How would you deal with a tangled ball of SQL spaghetti?

> The more lines the more risk for bugs.

I don't fully agree with this either, not all lines are equal. One big fat line of a 400 character long SQL query has higher chance of containing issues not easy to glance compared to 400 lines of Java code, and I say this even as a person who despises Java for various reasons.

Re: Advent of Code 2024 in pure SQL

#94

Post by xdavidliu »

qsort wrote: post #5
scop wrote: post #4

I 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.

parsing is most difficult for probably the first third of the problems. when you get to day 19 or so, the input is still just a grid or a bunch of ints just like day 1, but the algorithms required are considerably more challenging than the parsing part. (I've done all 25 problems in all years)

Re: Advent of Code 2024 in pure SQL

#95

Post by diggan »

hu3 wrote: post #83
trjordan wrote: post #18

If 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...

I'm on my phone so I can't open it now. Does it use Google App Script? Would be a way to gain extra power I think.

> Does it use Google App Script? Would be a way to gain extra power I think.

Isn't that just straight up JavaScript at that point? Feels kind of like cheating if the goal is to complete AoC with a spreadsheet.

Re: Advent of Code 2024 in pure SQL

#96

Post by diggan »

arkh wrote: post #91
coliveira wrote: post #34

Earlier quoted context omitted.

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...

My problem with Prolog is every time I want to start using it I feel like I'm populating a database then doing queries on it. So it feels like SQL with another syntax and less power. I'm sure I'm wrong and missing something but that's where I stop.

> I feel like I'm populating a database then doing queries on it. So it feels like SQL

I'm not sure what database technology/data storage that doesn't involve doing those two things to get started.

I haven't done any Prolog, but Datalog which is similar and focused on querying data, and the benefits of Datalog for me is that you can write complex/medium-complex queries a lot easier than in SQL, at least for me. Simpler queries are just less characters, but pretty much the same beyond that.

Probably helps that the Clojure ecosystem embraced Datalog so it mostly feels like writing Clojure code although it's really Datalog. You don't get that same feeling regardless of what SQL library/DSL you use.

Re: Advent of Code 2024 in pure SQL

#97

Post by sharpy »

phartenfeller wrote: post #75

Nicely done. I know this seems crazy at first but in my opinion big SQLs are one of the best ways to store complexity. The problem being complex is the issue. SQL is a standard, condensed, extremely performant, actually testable, and logical language. Sure, not anybody can instantly maintain it but that would be the same as if it was a lot of lines and functions in Java. The more lines the more risk for bugs. I also…

Once upon a time, as an intern, I had the 'fun' task of optimizing the performance of a stored procedure written by someone with a math phd. It was more than 6 pages when printed, and took more than 30 minutes to run (it was used in billing), and had no tests.

Ended up rewriting it in native code, and it run in less than a second. Most of the work was proving it produced same results... and writing and documenting test cases, so next person wouldn't have to go through that.

After that experience, I have generally avoided putting a lot of business logic in SQL...

Re: Advent of Code 2024 in pure SQL

#99

Post by zX41ZdbW »

tveita wrote: post #56

I 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...

I'd like to check what is the tuple explosion problem.

Re: Advent of Code 2024 in pure SQL

#100

Post by coliveira »

arkh wrote: post #91
coliveira wrote: post #34

Earlier quoted context omitted.

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...

My problem with Prolog is every time I want to start using it I feel like I'm populating a database then doing queries on it. So it feels like SQL with another syntax and less power. I'm sure I'm wrong and missing something but that's where I stop.

Prolog is in fact a kind of database. However it is untrue that it has less power than SQL, just the opposite. Probably it feels harder to use because you're already so used to how SQL works.
Post reply on HN