The first complaint derives largely from the SQL language being intended to read link English text. Languages like this show up regularly, seemingly based on the misconception that syntax is what's hard about programming. Most of them fail, as they should. SQL didn't, because it was tied to the exceptionally useful relational database.
The second is best illustrated by showing an alternative approach as an example: Korma for Clojure (http://sqlkorma.com/). It's easy to compose queries from simpler queries, just as we compose functions from simpler functions. Views provide some of this.
The third, if it's solvable would make using relational databases much nicer. Instead of schemas being manually-created diffs full of imperative statements like create and alter, make them declarative and have software generate the diff. If transformations on the data itself are required between versions, require it to include a pure function describing said transformation. By default, require a function to transform it back as well unless it explicitly says what data is to be discarded.
I do prefer the more fluent-like interfaces though... MongoDB and RethinkDB in node for example, or using the LINQ extension methods with Entity Framework (not LINQ syntax itself, which I find much more difficult). Though with LINQ, it's often interesting how twisted what gets queried from the data source can be vs. what you actually need... but that's a problem with most ORMs.
I do find that SQL queries with Node/JS adapters is pretty damned natural compared to any ORM for Java or C# imo...
Then, "make them declarative and have software generate the diff". So you want the benefits of relational data without the pain, is that it? Why not use Hibernate like the oh so wise ones have told us to use only to now realize trying to bend relational tools into what a language designer's ideas are is maybe, probably, not the best idea after all and perhaps the reason that SQL and relational databases have withstood the test of time and Hibernate is on the road to death is that SQL and relational design were extremely, unabashedly well thought out and designed in the first place.
You read that almost right. See, I don't think the average human who's fluent in English but not SQL will be able to properly understand anything but the most basic queries. Sure,
SELECT * from users where username = 'remotehack';
is going to mostly make sense to the average person (but what's the * and ; for?), but then so will (select users (where {:username "remotehack"}))
The brackets won't make sense, of course, but we're talking about reading it, not writing, and they're not terribly important to that.Now, give that same average person
Select Distinct On (u.username, u.email)
u.username
,u.email
,l.browser
,l.login_time
From users u
Join logins l On l.username = u.username
Order By u.username, login_time Desc
and do you really think they'll have any idea what to expect that to return? This no longer reads like English.And no, when I ask for declarative schemas, I'm not asking for ORM. I'm asking for a system where I say what the schema is instead of saying how to create it, just as I say what data I want rather than how to retrieve it. This is not incompatible with any of the fundamental concepts of relational databases.
They exist, e.g., Dataphor, Rel, etc. But it's hard to displace SQL.
The first one is always demonstrated to be a terrible argument when someone creates a SQL alike for whatever NoSQL we're talking about.
The second one has been a more durable argument. But transactional semantics clearly are independent of query language! And technologies like Lustre and Spanner show that one can still have some measure of traditional transactional semantics in distributed systems (filesystems and databases, respectively). There are many applications where some degree of "eventually-consistent" is a great tool for making them scale, but this is often a function of what can be done in the event that inconsistencies create problems (e.g., a store selling more items of some product than it has available, a case where the store can refund the customer or delay delivery).
I'm extremely skeptical of NoSQLs, as you can tell. I would say that NoSQLs have NoPLACE. (Certainly as to that first argument.)
I'm also extremely skeptical of ORMs. So far as I can tell ORMs only ever add a layer of headaches. They seem to aim for simplifying the DB experience for developers and users, but the moment you step out of the small world of queries made simpler by the ORM... you're in for a world of hurt.