That's not implying that large, successful projects cannot be built upon SQL. We see them in the real world all the time.
We have awesome implementations of the language, but any productivity is in spite of a quirky language designed in the early 1970s, not because of it.
This says nothing about the quality of SQL as a language.
What I think is more interesting is: if you were to greenfield a language for a relational database, how much would it look like SQL?
> if you were to greenfield a language for a relational database, how much would it look like SQL?
Save for secondary concerns like syntax, it would be exactly the same in all respects except easier composability.
There is no low-level API to SQL servers to create competition, so this is like saying CSS has no competition in browsers whatsoever. Yes, it does not, because it was never allowed. Let's go make a browser competition as part of our weekend, or at least RDBMS, sure /s. ORMs with their "relations" etc are basically better DSLs over SQL databases which try to hide rough edges from an innocent user.
concisely, effectively, efficiently expressing ideas, it's unquestionably successful
Yeah, "group by case when cond1 then v1 when cond2 then v3 else v3 end" instead of "group by alias1". Because, you know, it's declarative, but not really: https://stackoverflow.com/a/3841804/3125367
Or fetching thousands of rows out of explosion of "select t.a, t.b, p.propname, p.propvalue from items t left join props p on t.id = p.item_id". Or inability to join two different subtables like 'props' and 'per_city_prices' simultaneously without exploding into infinity. Of course you can always make 3 queries and join at your place, which is neither effective nor efficient nor concise. A business wants simple [{a, b, props:[{name, value}, ...], per_city_prices:[{city, price}, ...], ...]. Can SQL do that? It can not.
Or getting corresponding non-aggregate values along with min/max results, which requires very funny self-joins if it's already e.g. a windowed aggregation.
SQL is cool for these relational... matrices(?), but sucks as a programming language in both syntactic and semantic parts. Some servers fixed few dumb parts of it, but not generally.
Yes... but there is only one Web, and many databases. Some of them don't use SQL. They are, in my opinion, and in the opinion of many other developers, inferior. They lost in the market in a fair fight.
Also if SQL sucks so much you can compile to SQL, like TS->JS. Many such solutions exist. All worse than SQL.
> ORMs with their "relations" etc are basically better DSLs over SQL databases which try to hide rough edges from an innocent user.
ORMs are developed by software engineers for software engineers. It's kind of silly to picture them as "innocent" or incapable to understand the relational model.
> https://stackoverflow.com/a/3841804/3125367
Does having an operational semantics make a language not declarative? That's not how I use words. Is Haskell not functional because it runs on a GRS?
For the rest of your post you're arguing about either syntax, stuff you solve with CTEs, or stuff you would just hand off to the programming language, so I'll just leave it at that.
Perhaps SQL is so good that it couldn't be replaced all these years. But yes, debugging could have been better.
It is as though we lived in a world where, like our own, Lisp invented garbage collection. But unlike our own world, in 2022, Lisp is the only garbage collected language anyone uses. Others were invented but that mostly stopped by the 80s.
Many people would like to replace Lisp, and keep in mind this is Lisp so lexical scope is only available in some implementations and people who want cross-platform compatibility don't use it. But without it, you have to manage your own memory.
That's SQL and relational databases. Relational databases with ACID guarantees aren't optional, they aren't a nice-to-have, they're foundational.
And we talk to them in SQL because... we talk to them in SQL.