Tutorial D, D, Rel and Their Relation to NoSQL

I mentioned in my last NoSQL post that developers complain that SQL is a lousy declarative language.  On some levels I agree with that.  But those same developers then damn all relational theory and data stores because of shortcomings in the SQL language.  This is wrong.  It is usually vendor implementations of SQL that are the problem.  There are relational languages other than SQL.  This post will cover some of them and how they are better than SQL in many regards.  

TutorialD is not really a language, but rather a specification co-authored by CJ Date.  It describes the characteristics that a good declarative, relational language should have.  CJ Date devised TutorialD as an educational aide in one of his books.  The "D", I believe, stands for "data".  Date believed that SQL was not a particularly good language for expressing relational concepts.  D was supposed to be a better alternative to SQL.  

• being able to declare and query vectors/arrays directly in D.  In other words, you don't pass a result set back to Java and load it into an array to display it. 
• better transitive closure query capabilities
• handling recursion better.  In fact I don't believe SQL has recursion at all.  Some vendors have "recursive CTEs", for instance, that help.  
• better readability than SQL.  Correlated subqueries are really hard to "walk".  Don't believe me...look at some of the SQL generated by ORM tools.  Tutorial D allows sections of code to be "variable-ized", almost like a macro.  
• You can "pipeline" and string commands together.  Think of the HAVING clause in SQL.  It is really just a WHERE clause generated against a previously aggregated set.  HAVING is unneeded and doesn't exist in D.  In reality you can actually pipeline in SQL using derived tables, CTEs, and temp tables.  So you can basically have a derived table that has a GROUP BY clause on it, and then a WHERE clause on that derived table.  In this regard I really like the HAVING clause...but to each his own.  
• JOINs in D are always NATURAL JOINs, which means the ON clause is never needed.  I really, REALLY wish TSQL had this feature.  A NATURAL JOIN assumes the ON clause is PK:FK.  This really reduces the code clutter.  In D you can always express an alternate JOIN condition, you simply use the WHERE clause.  
• "Presentation" elements are part of the D language, ie, you can pass a properly formatted (perhaps with css tags) result set that can be used directly by your application's display engine.  Oracle does this by embedding, for instance, PL/SQL directly in Oracle Forms.  I really hated this when I used in last century, but it does work.  And some people swear by it.  
• D just looks more like Java code, which can make it appealing for Java Jocks.  This makes it scary for report writers though.  Surprisingly, many NoSQL query languages do the exact same thing.  And one of the big complaints about NoSQL solutions is their lack of good report writing tools (there are no "plug-ins" that allow you to query, for instance, CouchDB directly from Crystal Reports).   

There is currently no real-world implementation of D, it is merely a proscriptive list of items that a good relational query language should expouse.  It is merely educational.  Rel is an open-source implementation of D, written in Java.  I'm not aware of anything that formally supports it.  

Perhaps it is time that SQL people understand what the NoSQL people hate about SQL.  Then we can focus on providing extensions that cover some of the things listed above that would make all of us more productive without having to abandon the many good things of the relational model.