A sequel to SQL? An intro to Malloy

Re:A sequel to SQL? An intro to Malloy by steve_g on Tuesday September 06, 2022 @01:00PM (#32739890)

If we still use math 100 years from now, we'll still use SQL. It's a fine way to query relational data, and relational data is a fine way to model reality.

I'd like to hear from people that think I'm wrong.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by randomdata on Tuesday September 06, 2022 @02:00PM (#32740697)

> If we still use math 100 years from now, we'll still use SQL.

Those are incongruent. Do you mean Western notation?

> It's a fine way to query relational data

It's quirky, but good enough for ad-hoc queries that I think it will be hard to overcome the momentum in that area.

It's not fine for application work, where you need things like composition. We've tried to solve those problems with ORMs, but the ORM is starting to fall out of fashion due to a number of problems of its own. SQL is not a great compiler target. I do eventually see something lower level built for programmers, not data analysts, rising up here. If SQL is compared to Javascript, something akin to WASM, perhaps.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by munk-a on Tuesday September 06, 2022 @02:19PM (#32740974)

ORMs, when best used (and we use them even though we're pretty SQL literate and maintain a lot of SQL) will survive forever, nothing beats an ORM for really dirt simple expressions that you want to be trivially testable. Never in my life do I want to see someone write an UPDATE query against a single table with no shenanigans with dynamic field support using string gluing to properly stitch in all the columns - this is something a known tool can do better, this is a great opportunity for an ORM.

A non-great opportunity for an ORM is anything I'd call a "report query" (some complex read-only query involving a lot of JOINs, a bunch of WHERE clauses and possibly some nested aggregation for funsies) - this is where you pull out the SQL (or alternative query language!) because an ORM will struggle to properly support all the functionality you need and because trying to tune a query being produced by an ORM (even just to make sure it's well aligned with logical indices) is a task that yields nothing but endless frustration.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by Scarbutt on Tuesday September 06, 2022 @02:43PM (#32741351)

Never in my life do I want to see someone write an UPDATE query against a single table with no shenanigans with dynamic field support using string gluing to properly stitch in all the columns

These are just convenient features that most ORMs provide and can exist entirely outside of ORMs, they are not the primary purpose of ORMs.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by munk-a on Tuesday September 06, 2022 @02:49PM (#32741443)

You are correct by their design. But by usage I've found that to be by far the most valuable thing that ORMs deliver. Making use of ORMs to power an ActiveRecord system in your codebase has only ever, to my observation, lead to pain. Querybuilders that are equipped with more advanced functionality around type security and response decoding are quite a valuable tool.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by steve_g on Tuesday September 06, 2022 @03:31PM (#32742087)

I meant "still use math" as a proxy for "still use formal languages to communicate".

Maybe in 100 years AI will be so powerful that we'll just ask our question in natural language and get the answer we need. Or maybe in 100 years AI will have harvested us for the iron in our blood. Either way we wouldn't need SQL anymore.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by cgh on Tuesday September 06, 2022 @02:21PM (#32741010)

The GP is referring to SQL’s mathematical roots: https://en.wikipedia.org/wiki/Tuple_relational_calculus

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by randomdata on Tuesday September 06, 2022 @03:41PM (#32742224)

Then the statement resolves to "If we still use math 100 years from now, we'll still use math.", which is a rather silly statement. SQL and Western notation are interesting to compare in that they are the dominant, but not exclusive, languages used to describe their respective mathematical domains.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by pasc1878 on Tuesday September 06, 2022 @02:49PM (#32741451)

SQL does not fully implement Relational Algebra or Calculus, which are isomorphic.

See Many of Chris Dates' books and things like Tutorial D which do meet the ALgebra.

SQL is near enough the theory to work and also has had so much effort put into making it work fast, reliably and scale for volume that a new language has too much to overcome even if it can deal with all cases. So it won't be replaced soon.

However 100 years is longer than SQL had been around so a proper relation server could come around, there is just too much uncertainty.

[ Parent | on HN ]

Re:A sequel to SQL? An intro to Malloy by TillE on Tuesday September 06, 2022 @02:54PM (#32741531)

It's pretty obviously silly to have an unavoidable text parser in between code and data. We've reached the point where it's fairly low overhead, but it's still not nothing.

[ Parent | on HN ]