4 ms·

In the comments here so far, we see a pattern we've seen before. When someone suggests doing something in SQL, there's a lot of concern about SQL being a very l

In the comments here so far, we see a pattern we've seen before. When someone suggests doing something in SQL, there's a lot of concern about SQL being a very limited programming language where it's hard to do proper engineering. Here's I would really love to know: why is it that SQL is, to first order, the only language used to interact with databases, and SQL has about the same features as it did in the 70s? It seems analogous to if the general-purpose programming world stopped with C.

maxfurman 4y ago
Plenty of SQL features have been added since the 70s, notably window functions (which TFA relies on heavily). Most of the major databases are from the 80s, and even new kid on the block MySQL has been around since the mid 90s. SQL draws a very hard line between the expression of the query and the AST that is used in the actual implementation. Database vendors like this aspect because they are free to implement whichever optimizations they want, but application developers want to build queries programmatically and optimize them themselves before passing them to the db engine, hence the tension in threads like these.
bob1029 4y ago
> why is it that SQL is, to first order, the only language used to interact with databases, and SQL has about the same features as it did in the 70s? Because SQL is effectively a domain-specific language. If you added 100+ additional keywords/functions/etc., do you think it would be easier or more difficult for the average developer to build something clean with it? I look at SQL like a pile of bricks. You don't want complicated, unicorn bricks or you won't be able to fit anything meaningful together. Experienced masons almost certainly prefer their materials to be as dumb and consistent as possible.
- CRConrad 4y ago
  > You don't want complicated, unicorn bricks or you won't be able to fit anything meaningful together. Experienced masons almost certainly prefer their materials to be as dumb and consistent as possible. And now we know what's gone wrong with Lego for the last two-three (close to four?) decades. Funny – and sad! – how popular this shit has been on sites like this, though. Dare one hope that that popularity might begin to wane? Idunno
dventimi 4y ago
I believe the PC revolution gave a few generations of programmers the mistaken belief that imperative languages with familiar features (Basic, Pascal, C, Perl, Python, Java, etc.) are the only or the best way to interact with computers. Forms of interaction developed earlier (Forth, Prolog, SQL, etc.) were learned later, grudgingly, if at all. SQL was viewed with disdain, a necessary evil to be held at arm's length. That stalled evolution of SQL, the success of other query languages, or really anything that didn't fit the Algol-style "general purpose programming language" blinders. Mercifully, finally, the cold war against SQL in particular and against relational databases in general seems to be thawing. Articles like this one exemplify that trend

maxfurman 4y ago

Plenty of SQL features have been added since the 70s, notably window functions (which TFA relies on heavily). Most of the major databases are from the 80s, and even new kid on the block MySQL has been around since the mid 90s. SQL draws a very hard line between the expression of the query and the AST that is used in the actual implementation. Database vendors like this aspect because they are free to implement whichever optimizations they want, but application developers want to build queries programmatically and optimize them themselves before passing them to the db engine, hence the tension in threads like these.

bob1029 4y ago

> why is it that SQL is, to first order, the only language used to interact with databases, and SQL has about the same features as it did in the 70s? Because SQL is effectively a domain-specific language. If you added 100+ additional keywords/functions/etc., do you think it would be easier or more difficult for the average developer to build something clean with it? I look at SQL like a pile of bricks. You don't want complicated, unicorn bricks or you won't be able to fit anything meaningful together. Experienced masons almost certainly prefer their materials to be as dumb and consistent as possible.

CRConrad 4y ago
> You don't want complicated, unicorn bricks or you won't be able to fit anything meaningful together. Experienced masons almost certainly prefer their materials to be as dumb and consistent as possible. And now we know what's gone wrong with Lego for the last two-three (close to four?) decades. Funny – and sad! – how popular this shit has been on sites like this, though. Dare one hope that that popularity might begin to wane? Idunno

dventimi 4y ago

I believe the PC revolution gave a few generations of programmers the mistaken belief that imperative languages with familiar features (Basic, Pascal, C, Perl, Python, Java, etc.) are the only or the best way to interact with computers. Forms of interaction developed earlier (Forth, Prolog, SQL, etc.) were learned later, grudgingly, if at all. SQL was viewed with disdain, a necessary evil to be held at arm's length. That stalled evolution of SQL, the success of other query languages, or really anything that didn't fit the Algol-style "general purpose programming language" blinders. Mercifully, finally, the cold war against SQL in particular and against relational databases in general seems to be thawing. Articles like this one exemplify that trend