Comment by YuechenLi
6 hours ago
SQL is what it is today because it is battle tested and has to handles a very hard problem of handling arbitrary concurrent reads/writes, so the likely scenario is that trying to replace general SQL wholesale will just end up making a worse, less tested version of SQL that developers are less familiar with. So, I think the best query language is probably whatever query feature that's already in your backend language, LINQ for C# for example. The only room for an SQL replacement in my opinion is if you are willing to trade flexibility for speed a la TigerBeetle.
The good thing about having built your own programming language via LLM nowadays is that you don't really have to speculate about a theoretical language when you can just have Codex/Claude implement it and try it out for yourself. I did it yesterday when I wanted to try out this theoretical high-performance database architecture that I had in mind and just added query functionalities to the language I already have.
If anyone is interested about the results, the default naive mode for this new database is ~0.2x the speed of concurrent durable mutation workloads, but if you specialize it to the particular application, you can get ridiculous 50-100x performance increases on filters and maps at the cost of flexibility and more upfront design. Experimental results are promising, definitely not production ready though.
doesnt meant the syntax isnt a pile of dog farts
I agree, yeah, SQL syntax is awful. But the easier solution is what pretty much what backend has converged on, have something in your backend programming language that lowers to SQL so you never have to write any raw SQL at all except as a low-level escape hatch, so that in most instances SQL just becomes an IR that nobody really needs to think about in normal application code.
Are we really this devolved as coders? We can’t handle different syntaxes? We need LLMs to write queries? What the heck is going on with our industry?
Old man rant off.
I don't take it as too-much-syntax in the brain[0], but all of the problems bad syntax causes. We could still be writing code in assembly, but we have found that different languages make things easier or safer to construct.
I can trivially handle having to repeatedly bounce to the top-then-to-the-bottom of a query I am writing because I want to change the group-by or sorting order, but that is annoying friction. Since the language does not compose well, you need to keep most of the query in your head and cannot build it up piecemeal as easily as something like PRQL (https://prql-lang.org/)
[0] Although, it would be incredible if I could write timestamp formatting without having to look up the bespoke vendor incantation every time I switch dialects.
1 reply →
The difficulties that even experienced programmers have with SQL are far more than just the syntax. And, given what most people need the database for, that difficulty is pretty disproportionate to the complexity of the task.
I think the “it’s just syntax bro, learn it!” critique is about as ill-fitting as the claim that embedding a scripting language in a larger program is pointless because “assembly/C89 is just syntax bro, learn it!”
1 reply →
Not even an old man rant SQL isn't that hard to learn. I never had a problem with the syntax. Not everything needs to look like C. Remember when every complained about Python's whitespace indenting? Seems like everyone got over it.
Syntax affects readability and writing speed a lot
No, SQL is what it is today because it was crappy in the beginning and no one managed to replace it.
It was only a partial implementation of the relational model, we could have been so much better had it not become the standard
It’s a fine tool for most data storage/retrieval jobs.
Crying about some theoretical relational model doesn’t do anything to further your point.
The sad reality is that having something that works, even if badly, is better than having a theoretically elegant architecture that is not implemented. See JS or Linux vs Hurd for other examples.
Ask yourself this question, supposedly somebody made the full implementation of the relationship model into a database engine tomorrow, will you use it yourself, and can you convince your company to use it in place of SQL? Again, I wish this wasn't the case, but I'm not sure if there is anything we can do about the adoption problem.
...but we've had full implementations of the relational model for decades, with great performance etc. It's just a query language. A DB can use whatever query language it implements. Just like JS, there were schemes before JS (including the working browser one before management made Eich redo it into JS), there were other languages used in the browser even!