I'm working in a relational language that if it work as I wish, could eventually be put on top of a RDBM like sqlite or layer for other DBs:
https://github.com/Tablam/TablaM
It have ideas similar to QUEL...
A Short Story About SQL’s Biggest Rival
31–40 of 128 posts
Re: A Short Story About SQL’s Biggest Rival
#32Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.
Next you're going to complain about NaN != NaN.
Re: A Short Story About SQL’s Biggest Rival
#33The article talks about how SQL lacks composability. I would like to know everyones thoughts about this.
This is a huge issue with programming in general not exclusive to SQL. Everyone would like to build programs that are modular and reusable but programming paradigms have been traveling in directions that prevent this from happening. Many people turn to design patterns or microservices to try to deal with this organizational issue but they fail to see that the lower level programming paradigm itself is the precursor to the problem.
In SQL the problem occurs in the statement itself. The WHERE clause or the SELECT clause cannot be reused anywhere else. I can't modularize a where clause and put it in another SQL statement. I have to rewrite the entire clause to reuse it.
In OOP the same issue occurs. In OOP your class tends to contain methods that are not combinators, or in other words methods that modify a free variable. Due to this like the SQL expression, Objects cannot be decomposed either. I cannot reuse a setter in another class or anywhere else outside of the context of the free variable it modifies.
In both cases there comes a time in the future of an application where programmers realize that similar logic could be reused but structural problems are preventing the reuse from happening so they have to implement a hack to get around it.
The issue is that everyone is unaware of this trend at a low level. They are unaware that SQL lacks composability just like how they are unaware that OOP lacks composability as well. But they are aware of this issue at a higher level and they tend to call it "technical debt" or some high level design problem.
Case in point: https://news.ycombinator.com/item?id=24732789
Most commenters above talk about minor syntactical issues and fail to address what is not only IMO the main issue, but the main issue that the article itself is addressing. Likely because they're all unaware of the true nature of the composability issue and just didn't completely understand what the article was saying.
Also note that when I talk about composition in OOP I am not talking about "object composition." These are completely different usages of the word.
Re: A Short Story About SQL’s Biggest Rival
#34> … The language (SQL) is not very composable. This is a fact that most SQL users are not aware of. The relational algebra that SQL is based on is absolutely composable but SQL is not due to the inherent limitation of the language (as it was designed to be natural language-like). When you write "select x from a where z", you are actually building something along the lines of "from a" => "where z" => "select x" in the…
You're arguing about capability, whereas the post is arguing about the grammar itself. What you're describing is how to build a separate domain specific language that compiles to SQL (which there are quite a few of; e.g. C#'s Linq).
Quite a few query languages are equally capable (including, surprisingly, quite a few so-called graph languages, provided the SQL dialect provides a transitive closure), but SQL as a language has some undesirable properties (most of which are trade-offs for the fact that basic SQL is very easy to parse).
Re: A Short Story About SQL’s Biggest Rival
#35>If the world worked differently, we wouldn’t still be writing on QWERTY keyboards, or speaking English; technically superior alternatives like Dvorak and Esperanto would have taken over. Bad metaphor: There is no evidence for Dvorak's technical superiority to QWERTY, neither is there for Esperanto over other languages.
Dvorak is 25% more efficient than Qwerty using some very reasonable calculations: http://mkweb.bcgsc.ca/carpalx/?dvorak
And by some other measures (hand alternation of fingers) Dvorak is less efficient.
QWERTY isn't as bad as people make it out to be, and Dvorak isn't as good as people make it out to be.
There are keyboard configurations that are better than both, but nobody uses them because you'll never be able to use anybody else's keyboard.
Re: A Short Story About SQL’s Biggest Rival
#36I'm working in a relational language that if it work as I wish, could eventually be put on top of a RDBM like sqlite or layer for other DBs: https://github.com/Tablam/TablaM It have ideas similar to QUEL...
Just for comparison, a functional approach is a major alternative to relational and set-oriented models and query languages. The difference is that functions and operations with functions are first class elements of the model.
One version of it is implemented in this project:
https://github.com/prostodata/prosto - Functions matter! No join-groupby, No map-reduce
Re: A Short Story About SQL’s Biggest Rival
#37can anyone find examples of what QUEL looked like? If we had a more composable query language being used instead of SQL, I wonder if that would have effected the course of ORMs, which arguably end up being as much about composable models of queries as they do about actual object mapping.
Re: A Short Story About SQL’s Biggest Rival
#38"Mike Stonebraker of Ingres didn’t even bother to show up at the committee meeting to make the (quite strong) case for adopting QUEL because he was ideologically opposed to setting technology standards. It was the behavior of an intellectually arrogant academic rather than a prudent businessman protecting the interests of his company."
Some might call the behavior principled, rather than arrogant.
Re: A Short Story About SQL’s Biggest Rival
#39"Mike Stonebraker of Ingres didn’t even bother to show up at the committee meeting to make the (quite strong) case for adopting QUEL because he was ideologically opposed to setting technology standards. It was the behavior of an intellectually arrogant academic rather than a prudent businessman protecting the interests of his company." Some might call the behavior principled, rather than arrogant.
Those are not mutually exclusive. (One could add "foolish" and "short-sighted" to the list of potentially compatible adjectives.)
Re: A Short Story About SQL’s Biggest Rival
#40> … The language (SQL) is not very composable. This is a fact that most SQL users are not aware of. The relational algebra that SQL is based on is absolutely composable but SQL is not due to the inherent limitation of the language (as it was designed to be natural language-like). When you write "select x from a where z", you are actually building something along the lines of "from a" => "where z" => "select x" in the…
Subqueries, named VIEWs, CTEs, etc all make SQL compostable ?