Comment by YuechenLi | Hacker News Reader

Comment by YuechenLi | Hacker News Reader

Parent Full thread

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.

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

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!

I never did Scheme in the browser, there was no "redo".

https://x.com/BrendanEich/status/1997032329689346359

Oh! Thank you for correcting me.

Previously, I've seen it described (including on Wikipedia) that you were hired to embed Scheme, but then they made you change it right before delivery.

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.

No one cries about theoretical things

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.

Does CTE not allow composability?

Is it really THAT terribly difficult to replace "SELECT vars FROM table..." with "FROM table SELECT vars...", so that tools can provide suggestions ?

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!”

I take what you’re saying about difficulty being disproportionate to the task as an indicator of ability.

It’s literally so damn simple to knock out a database & some crud functions either as a desktop app or a website that the complaints in this thread are hilarious.

That comes across as arrogant and rude. Assuming you actually want to engage, I discussed some of the reasons that this can be hard here: https://news.ycombinator.com/item?id=49411927

The link in the top comment further expands on the cognitive overhead: https://www.scattered-thoughts.net/writing/against-sql

Particularly relevant is the part of that link which discusses having to pervasively refactor queries to add even a simple synthetic join or computed column. That’s a pain in the ass even for experienced DBAs, and is fundamentally not time well spent for row-at-a-time cases that are often, as you said, simple CRUD.

Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for?

The example of pervasive refactor is a bit of a contrived example to be honest. Get the id of the record you're discussing with your pre-conditions and then retrieve the data you're after.

At least in SQL Server select x2 from foo group by x+1 as x2 you'd use select x+1 as x2 from foo group by x.

I've read your article and it's written well enough, I'm just not sure that's as big a hit piece as you think it is nor do I think here is the place to post a full rebuttal.

>Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for?

I think on the contrary that esoteric features not used as commonly utilised deserve to be esoteric to use. The common path should be the easiest. That SQL is used by different professions and not just IT related ones is testament to a good language. You won't find BA's using C to write reports for instance. There's A LOT of value in that.

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

Writing speed is not really relevant anymore, LLMs do it. Reading is what matters most.

:rolleyes:

Reply on news.ycombinator.com