4 ms·

A Critique of Modern SQL and a Proposal Towards a Simple and Expressive QL [pdf]

3 points by tison 3y ago

deleted 3y ago
[deleted]
ttfkam 3y ago
tl;dr: Valid critiques. Still doesn't matter. > Syntactic Order Is Not Semantic Order 100% true. Not enough to justify throwing out all the stuff built upon SQL. There's the rub. It can't just be better. It has to be so much better that processing time, retraining costs, and rewriting (even in greenfield) are economically and socially justified. Humans linguistically adjust to reordered semantics rather well. In Japanese, the verb comes last in a sentence. In German, the verb can be in the second position (most common), initial position (verb first), and clause-final position. In Spanish, verbs are often in the first position since conjugation determines the subject. We can argue about which language is best or most efficient, but once you have a large population that speaks and is literate in that language, it stops mattering anymore. Rust is supplanting C and C++ in many venues not just because of grammar (in fact, it might even be in spite of grammar), but because there are tangible and measurable advantages in the real world with regard to memory safety and code maintenance. As long as the arguments against SQL remain firmly in the realm of aesthetics, it's not going anywhere. You need examples where the replacement actually benefits the efficiency or safety of a database engine without sacrificing existing functionality and use cases. I firmly believe this to be possible and likely in the future, but I think far too many critics and naive syntax haters underestimate the amount of work involved. We're talking "whole new operating system from scratch and then build popularity" level of difficulty here. Google has amazing resources available to it and very smart people. They made the Spanner database engine largely from scratch that supplanted many assumptions about the inviolability of the CAP theorem at scale using custom hardware, atomic clocks, and a lot of novel techniques. And yet they still put an SQL layer on top of it. There's tons of research into "cleaner", "more elegant" options than SQL just like the paper listed here. Google's no stranger to new language development from Dart to Go to Carbon. And perhaps Dart is the best example of this principle. Looking at the language, many would argue it is an objectively better language than JavaScript. Google controls the engine underlying Chrome, Opera, and Edge now. The Blink engine has a commanding level of marketshare. But like VBScript before it, Dart was never widely adopted for web development, even for internal web apps where Chrome/Chromium are mandated for use. Dart may have been "better", but it wasn't "better enough" to displace a massive install base and legions of developers already familiar with JS. Cosmetic improvements to JS, massive VM optimization efforts, and the introduction of the typed superset known as TypeScript have proved more than enough to keep usurpers at bay. It's gonna take a lot more than academic papers and translation layers. To all the SQL haters out there: "You're gonna need a bigger boat."

3 points by tison 3y ago

deleted 3y ago

[deleted]

tl;dr: Valid critiques. Still doesn't matter. > Syntactic Order Is Not Semantic Order 100% true. Not enough to justify throwing out all the stuff built upon SQL. There's the rub. It can't just be better. It has to be so much better that processing time, retraining costs, and rewriting (even in greenfield) are economically and socially justified. Humans linguistically adjust to reordered semantics rather well. In Japanese, the verb comes last in a sentence. In German, the verb can be in the second position (most common), initial position (verb first), and clause-final position. In Spanish, verbs are often in the first position since conjugation determines the subject. We can argue about which language is best or most efficient, but once you have a large population that speaks and is literate in that language, it stops mattering anymore. Rust is supplanting C and C++ in many venues not just because of grammar (in fact, it might even be in spite of grammar), but because there are tangible and measurable advantages in the real world with regard to memory safety and code maintenance. As long as the arguments against SQL remain firmly in the realm of aesthetics, it's not going anywhere. You need examples where the replacement actually benefits the efficiency or safety of a database engine without sacrificing existing functionality and use cases. I firmly believe this to be possible and likely in the future, but I think far too many critics and naive syntax haters underestimate the amount of work involved. We're talking "whole new operating system from scratch and then build popularity" level of difficulty here. Google has amazing resources available to it and very smart people. They made the Spanner database engine largely from scratch that supplanted many assumptions about the inviolability of the CAP theorem at scale using custom hardware, atomic clocks, and a lot of novel techniques. And yet they still put an SQL layer on top of it. There's tons of research into "cleaner", "more elegant" options than SQL just like the paper listed here. Google's no stranger to new language development from Dart to Go to Carbon. And perhaps Dart is the best example of this principle. Looking at the language, many would argue it is an objectively better language than JavaScript. Google controls the engine underlying Chrome, Opera, and Edge now. The Blink engine has a commanding level of marketshare. But like VBScript before it, Dart was never widely adopted for web development, even for internal web apps where Chrome/Chromium are mandated for use. Dart may have been "better", but it wasn't "better enough" to displace a massive install base and legions of developers already familiar with JS. Cosmetic improvements to JS, massive VM optimization efforts, and the introduction of the typed superset known as TypeScript have proved more than enough to keep usurpers at bay. It's gonna take a lot more than academic papers and translation layers. To all the SQL haters out there: "You're gonna need a bigger boat."