People re-inventing SQL reminds me of the same people that keep trying to re-write standard Staff Music Notation.
Yeah, it's not perfect, but the suggested replacements are marginal gains, if anything.
In order to replace SQL, you probably need something like a 10x improvement, so it sells like hotcakes. Nothing about those examples screams that sort of improvement.
I mean, cool they put some stuff on the left instead of the right. And I guess the select clause is in a little better order now. Yay.
On the other hand, it shows how when something gets popular enough it gets stuck in place, unable to progress slowly towards better, because we keep calling it good enough and all marginal improvements that accumulate to something significant over time are rejected.
And this friction can be a significant problem, because it can cause systems to die overtime by being suddenly replaced, disrupted, from below by something that is a major improvement but completely incompatible with the status quo. Think of it as having a devastating earthquake after a long period of complete calm.
This is not good for anyone, we will be much better served by small gradual improvements to existing systems. This is how we came to be ourselves through evolution.
Additions and improvements to SQL standards happen all the time though. My favourite rdbms drops a new version every few months with exciting new features. This sounds more like the slow and steady improvement you speak of than all these proprietary newfangled languages that show up every few months, never to be heard from again.
Not quite. SQL and the web are examples of standards that evolve by accumulating cruft. They try to address more and more unaddressed edge cases by constantly adding new slightly different ways of doing the same thing without addressing the core problems that cause this complexity in the first place. Evolution is not about adding features alone. It’s about also removing and changing features. If you read carefully the linked site, it offers way, way more than a fancier way to do a SELECT.
The SQL standard is also adding features that go ignored about most SQL databases, because the client libraries won’t support to them and they’re out of sync with the server and so on and so on.
Be that as it may, every time I see a new database product I open the page, and if it doesn't support SQL, more often than not I never think about it and don't think about it again. I am never going to invest in some proprietary query format for marginal gains over SQL, seeing as I'm yet to run into a situation where having to write SQL precludes solving a problem I had. I really don't want data stores to adopt the frenetic rate of change seen in other areas of the field (like JS, shudder).
I think Postgres does an excellent job staying up to date with ANSI SQL; all other implementations (other than sqlite) are largely irrelevant to me.
Consider the paradox. You don’t care about proprietary standards, but you use a database that stands mostly alone in implementing the standards you track, and also it has many proprietary extensions on its own.
I’m curious if PG supports heterogenous nested results (data trees) this one of the biggest omissions from the standard on all dbs I use to the point I can’t use this at all.
Yeah, it's not perfect, but the suggested replacements are marginal gains, if anything.
In order to replace SQL, you probably need something like a 10x improvement, so it sells like hotcakes. Nothing about those examples screams that sort of improvement.
I mean, cool they put some stuff on the left instead of the right. And I guess the select clause is in a little better order now. Yay.