I am no fan of the syntax of SQL, however the authors solution of making SQL more procedural is (imo) correctly identifying an issue but then reaching for the wrong tool to fix it.<p>When I am authoring SQL, I find the declarative and relational concepts extremely powerful and well suited to the problem I am solving.
> and after GROUP, an extra BY needs to be written.<p>group /= groupBy.<p>Group just put things in groups. GroupBy allows for a function on the item to be used (think passing a custom comparator into a sort() function). In SQL's case I think this is just limited to a column id, but I could be wrong.<p>> The main downside of being like natural language is non procedural. Program logic is generally executed step by step<p>SQL has thrived on being non-procedural. It is high-level and abstract, and its various implementations make much better optimisations than would the average-idiot-programmer-in-a-hurry.<p>All that would go out the window if the programmer had to write how to do things. Forget 'repeatable read' or 'linearisable' or any correctness guarantees provided by a database - if it's up to the programmer to write <i>how</i>, not <i>what</i>, then your correctness guarantees are basically: "I hope every programmer who touched this codebase took the right number of locks in the right order at the right time".
The authors argument that SQL's english-like syntax is a "well-intentioned error" overlooks the accessibility it provides. SQL, inspired by relational algebra, enables set-based operations, distinct from procedural programming's linear approach.<p>This is why SQL has endured for so long.<p>That mathematical base allows for efficient data manipulation across vast datasets.<p>To his point that no other languages strive to be spoken like, languages like ruby (and python to a degree )have successfully adopted a natural, english-like syntax, enhancing readability and developer productivity.<p>Emphasizing procedural over declarative concepts misinterprets SQL's core advantage: expressing complex data relationships and manipulations succinctly. Such perspectives miss the broader utility of making programming languages approachable and efficient for diverse tasks and user backgrounds.<p>Side rant: I just wish SQL was more composable.
Lately I've been experimenting the usage of LLMs for the explainability of SQL stored procedures with exceptionally good results - think about identifying important fields, linking them to existing glossaries, expanding said glossaries, etc.
I wonder how much SQL looking like natural language helped for my use case.
I find the author to be fairly out of touch with modern programming languages based on the assertions made in the article. But more importantly, I think leaning into procedural programming is a fundamental misunderstanding of the power of declarative syntax and also does not take advantage of the RDBMS’ biggest strength: the ability to think in sets.
While interesting, it's hard to identify any component of the author's argument that isn't fundamentally flawed.<p>Ambiguity is not "the true advantage" of natural language and certainly not one we want a query language to adopt.<p>Pointing to the limits on the complexity of SQL queries most business folks can write overlooks the fact that <i>there are SQL queries that most business folks can write</i>.<p>Wanting to make SQL more procedural is a terrible idea, for all the reasons already expressed more eloquently in this thread than I can.
Anyone who has had to sift through large BNFs such as [0, 1] to find that the syntax error was a syntactically significant "TO" knows that this is the case. Natural language has synonyms, computer languages really should avoid synonyms and also any spurious syntactic sugar.<p>[0] <a href="https://www.postgresql.org/docs/13/sql-altertable.html" rel="nofollow">https://www.postgresql.org/docs/13/sql-altertable.html</a><p>[1] <a href="https://www.postgresql.org/docs/13/sql-commands.html" rel="nofollow">https://www.postgresql.org/docs/13/sql-commands.html</a>
It perhaps is an error from the point of view of the ”leading reporting tooling vendor in China” <a href="https://www.scudata.com/about-us/" rel="nofollow">https://www.scudata.com/about-us/</a> which starting in 2007 built their own Java NoSQL data warehouse+sqllite?!) platform.<p><a href="https://github.com/SPLWare/esProc">https://github.com/SPLWare/esProc</a>
<a href="https://blog.scudata.com/qa-of-esproc-architecture/" rel="nofollow">https://blog.scudata.com/qa-of-esproc-architecture/</a><p>Composibility aside, I’m more interested in their identification of limits of relational algebra and the alternative keywords they use for things difficult to optimize in SQL engines than their critique of using English. For that, see <a href="https://c.scudata.com/article/1694595486828?p=1&m=0" rel="nofollow">https://c.scudata.com/article/1694595486828?p=1&m=0</a>
While I don't agree with the conclusion of the article, I still wonder if there's an alternative to SQL that is:<p>- declarative<p>- easy to understand<p>- scales well with the complexity of the query<p>Perhaps it could look and feel like a functional programming language but underneath uses the same execution engine as SQL<p>I've seen a few attempts at it, but none of them have clicked with me.<p>Thoughts?