> And yet someone proficient in SQL will not necessarily be able to read a traditionally-written lambda calculus expression as the languages differ significantly (and not just because of tables), so I think this proves my point that there are different, and hopefully better, ways to express the interaction with the database. There is no reason why the protocol has to be exactly as SQL is. There are theoretically an infinite number of ways to communicate the same intent to a RDBMS.
First, lambda calculus isn't a language -- at least, not in the typical sense. It's a mathematical logic construct. It's more akin to geometry than to a programming language. Same applies to relational algebra.
And of course lambda calculus and relational algebra differ significantly... Their domains are completely disjoint. I was not comparing them in this way. I'll restate my premise:
If we consider SQL a mapping of relational algebra operators to SQL operators [0], then any other language which also maps to relational algebra will not be significantly different. Thus, complaining about SQL being a singularity is kinda like complaining that relational algebra, lambda calculus, or any other mathematical constructs are singularities.
> For instance, SQL does not do composability well. There is no fundamental reason why you should not be able to write query fragments, simplifying the way many queries are constructed and avoiding the huge mess that monolithic, hard to debug, queries often become. It is simply that SQL does not allow for it. A better API could improve on this significantly, without losing any features a relational database provides.
You can compose SQL with views. Non-materialized views act as pure SQL composition. Materialized views allow precalculation of subexpressions.
Most of the big databases also support common table expressions, which allow for decomposition within a single query.
> You don't have to throw all database theory out the window just to change the API away from one that was designed 40 years ago.
Of course not. The problem is that any new SQL would just be a new mapping for the same underlying relational algebra. "Welcome to the new SQL, same as the old SQL."
[0] It's not, because tables aren't relations. However, the operators are similar enough that parallels are easily drawn.
> First, lambda calculus isn't a language -- at least, not in the typical sense.
There are common ways to express lambda calculus expressions in order for people to communicate those expressions with each other, which is very much a language. After all, we are talking about the language of SQL here, not the mathematical concepts that lie beneath the language. Don't confuse what SQL is able to achieve with the way SQL is written. We are discussing only the latter.
> The problem is that any new SQL would just be a new mapping for the same underlying relational algebra.
And general purpose programming languages map to the same underlying turing machine. That hasn't stopped us from coming up with variations in language to improve the developer experience, even if they are all quite similar at the end of the day. Let's face it, if you can program in one general purpose programming language, you can program in them all. There are no real differences between them. The only thing to learn when switching languages is the grammar and idioms of the language. The underlying mathematical theory never changes.
You could just as easily say "Welcome to the new C, same as the old C." And yet, the new C has proven to be quite valuable when it comes to developer productivity and happiness. There is very much room for the same in SQL land, if someone was ever motivated enough to look for it. I maintain that NoSQL becoming synonymous with unstructured key-value/document data stores has killed what motivation there may have been though.
First, lambda calculus isn't a language -- at least, not in the typical sense. It's a mathematical logic construct. It's more akin to geometry than to a programming language. Same applies to relational algebra.
And of course lambda calculus and relational algebra differ significantly... Their domains are completely disjoint. I was not comparing them in this way. I'll restate my premise:
If we consider SQL a mapping of relational algebra operators to SQL operators [0], then any other language which also maps to relational algebra will not be significantly different. Thus, complaining about SQL being a singularity is kinda like complaining that relational algebra, lambda calculus, or any other mathematical constructs are singularities.
> For instance, SQL does not do composability well. There is no fundamental reason why you should not be able to write query fragments, simplifying the way many queries are constructed and avoiding the huge mess that monolithic, hard to debug, queries often become. It is simply that SQL does not allow for it. A better API could improve on this significantly, without losing any features a relational database provides.
You can compose SQL with views. Non-materialized views act as pure SQL composition. Materialized views allow precalculation of subexpressions.
Most of the big databases also support common table expressions, which allow for decomposition within a single query.
https://en.wikipedia.org/wiki/Hierarchical_and_recursive_que...
> You don't have to throw all database theory out the window just to change the API away from one that was designed 40 years ago.
Of course not. The problem is that any new SQL would just be a new mapping for the same underlying relational algebra. "Welcome to the new SQL, same as the old SQL."
[0] It's not, because tables aren't relations. However, the operators are similar enough that parallels are easily drawn.