6 ms·

And compared to what we had before SQL, it is much easier to use, and a lot more people are able to use it.

by ako 1y ago

ameliaquining 1y ago
Is that really because of the English-esque syntax, rather than because it was a step forward in semantic expressivity? If SQL looked like, say, C#'s LINQ method syntax, would it really be harder to use?
- 9rx 1y ago
  > Is that really because of the English-esque syntax Well, what we had before SQL[1] was QUEL, which is effectively the same as Alpha[2], except in "English". Given the previous assertion about what came before SQL, clearly not. I expect SQL garnered favour because it is tablational instead of relational, which is the quality that makes it easier to understand for those not heavy in the math. [1] Originally known as SEQUEL, a fun word play on it claiming to be the QUEL successor. [2] The godfather language created by Codd himself.
  - dmkolobov 1y ago
    Do you have any advice for understanding the difference between "relational" and "tablational"? I remember hearing something about how SQL is not really relational from my college professor, but we never really explored that statement.
    - razakel 1y ago
      Per the SQL specification: >SQL [...] is a database language [...] used for access to pseudo-relational databases that are managed by pseudo-relational database management systems (RDBMS). >SQL is based on, but is not a strict implementation of, the relational model of data, making SQL “pseudo-relational” instead of truly relational. >The relational model requires that every relation have no duplicate rows. SQL does not enforce this requirement. >The relational model does not specify or recognize any sort of flag or other marker that represents unspecified, unknown, or otherwise missing data values. Consequently, the relational model depends only on two-valued (true/false) logic. SQL provides a “null value” that serves this purpose. In support of null values, SQL also depends on three-valued (true/false/unknown) logic. Or, in other words, "relation" does not mean the relations between the tables as many assume: the tables, as a set of tuples, are the relations.
    - 9rx 1y ago
      Quite simply: A relation is a set of tuples, while a table is a list/multiset of tuples. The Alpha/QUEL linage chose relations, while SQL went with tables. Notably, a set has no ordering or duplicates — which I suggest is in contrast to how the layman tends to think about the world, and thus finds it to be an impediment when choosing between technology options. There are strong benefits to choosing relations over tables, as Codd wrote about at length, but they tend to not show up until you get into a bit more complexity. By the time your work reaches that point, the choice of technology is apt to already be made. With care, SQL enables mimicking relations to a reasonable degree when needed, which arguably offers the best of all worlds. That said, virtually all of the SQL bugs I see in the real world come as a result of someone not putting in enough care in that area. When complexity grows, it becomes easy to overlook the fine details. Relational algebra and calculus would help by enforcing it. But, tradeoffs, as always.
- AdieuToLogic 1y ago
  Before SQL became an industry standard, many programs which required a persistent store used things like ISAM[0], VISAM (a variant of ISAM[0]), or proprietary B-Tree libraries. None of these had "semantic expressivity" as their strength. > If SQL looked like, say, C#'s LINQ method syntax, would it really be harder to use? Yes. 0 - https://en.wikipedia.org/wiki/ISAM https://en.wikipedia.org/wiki/ISAM
noworriesnate 1y ago
But software developers often struggle to use sql and prefer using ORMs or analytical APIs like polars; the people who excel at sql are typically not programmers, they’re data engineers, DBAs, analysts, etc. Maybe a similar bifurcation will arise where there are vibe coders who use LLMs to write everything, and there are real engineers who avoid LLMs. Maybe we’re seeing the beginning of that with the whole bifurcation of programmers into two camps: heavy AI users and AI skeptics.
- nathanfig 1y ago
  Claude made this point while reviewing my blog for me: the mechanization of farms created a whole lot more specialization of roles. The person editing CAD diagrams of next year's combine harvester may not be a farmer strictly speaking, but farming is still where their livelihood comes from.
  - swader999 1y ago
    Land is scarce though. The amount of software work that needs doing might not be, it could be infinite or probably more tied to electrical capacity.
  - deleted 1y ago
    [deleted]
  - dredmorbius 1y ago
    Strictly speaking, farming is where all our livelihoods come from, in the greatest part. We're all living off the surplus value of food production. (Also of other food, energy, and materials sourcing: fishing, forestry, mining, etc.) This was the insight of the French economist François Quesnay in his Tableau économique, foundation of the Physiocratic school of economics.
    - eru 1y ago
      You might find https://en.wikipedia.org/wiki/Margarine#Coal_butter https://en.wikipedia.org/wiki/Margarine#Coal_butter fascinating. > Strictly speaking, farming is where all our livelihoods come from, in the greatest part. We're all living off the surplus value of food production. I don't think farming is special here, because food isn't special. You could make exactly the same argument for water (or even air) instead of food, and all of a sudden all our livelihoods would derive ultimately from the local municipal waterworks. Whether that's a reductio ad absurdum of the original argument, or a valuable new perspective on the local waterworks is left as an exercise to the reader.

And compared to what we had before SQL, it is much easier to use, and a lot more people are able to use it.

by ako 1y ago

And compared to what we had before SQL, it is much easier to use, and a lot more people are able to use it.

Is that really because of the English-esque syntax, rather than because it was a step forward in semantic expressivity? If SQL looked like, say, C#'s LINQ method syntax, would it really be harder to use?

9rx 1y ago
> Is that really because of the English-esque syntax Well, what we had before SQL[1] was QUEL, which is effectively the same as Alpha[2], except in "English". Given the previous assertion about what came before SQL, clearly not. I expect SQL garnered favour because it is tablational instead of relational, which is the quality that makes it easier to understand for those not heavy in the math. [1] Originally known as SEQUEL, a fun word play on it claiming to be the QUEL successor. [2] The godfather language created by Codd himself.
- dmkolobov 1y ago
  Do you have any advice for understanding the difference between "relational" and "tablational"? I remember hearing something about how SQL is not really relational from my college professor, but we never really explored that statement.
  - razakel 1y ago
    Per the SQL specification: >SQL [...] is a database language [...] used for access to pseudo-relational databases that are managed by pseudo-relational database management systems (RDBMS). >SQL is based on, but is not a strict implementation of, the relational model of data, making SQL “pseudo-relational” instead of truly relational. >The relational model requires that every relation have no duplicate rows. SQL does not enforce this requirement. >The relational model does not specify or recognize any sort of flag or other marker that represents unspecified, unknown, or otherwise missing data values. Consequently, the relational model depends only on two-valued (true/false) logic. SQL provides a “null value” that serves this purpose. In support of null values, SQL also depends on three-valued (true/false/unknown) logic. Or, in other words, "relation" does not mean the relations between the tables as many assume: the tables, as a set of tuples, are the relations.
  - 9rx 1y ago
    Quite simply: A relation is a set of tuples, while a table is a list/multiset of tuples. The Alpha/QUEL linage chose relations, while SQL went with tables. Notably, a set has no ordering or duplicates — which I suggest is in contrast to how the layman tends to think about the world, and thus finds it to be an impediment when choosing between technology options. There are strong benefits to choosing relations over tables, as Codd wrote about at length, but they tend to not show up until you get into a bit more complexity. By the time your work reaches that point, the choice of technology is apt to already be made. With care, SQL enables mimicking relations to a reasonable degree when needed, which arguably offers the best of all worlds. That said, virtually all of the SQL bugs I see in the real world come as a result of someone not putting in enough care in that area. When complexity grows, it becomes easy to overlook the fine details. Relational algebra and calculus would help by enforcing it. But, tradeoffs, as always.
AdieuToLogic 1y ago
Before SQL became an industry standard, many programs which required a persistent store used things like ISAM[0], VISAM (a variant of ISAM[0]), or proprietary B-Tree libraries. None of these had "semantic expressivity" as their strength. > If SQL looked like, say, C#'s LINQ method syntax, would it really be harder to use? Yes. 0 - https://en.wikipedia.org/wiki/ISAM https://en.wikipedia.org/wiki/ISAM

noworriesnate 1y ago

But software developers often struggle to use sql and prefer using ORMs or analytical APIs like polars; the people who excel at sql are typically not programmers, they’re data engineers, DBAs, analysts, etc. Maybe a similar bifurcation will arise where there are vibe coders who use LLMs to write everything, and there are real engineers who avoid LLMs. Maybe we’re seeing the beginning of that with the whole bifurcation of programmers into two camps: heavy AI users and AI skeptics.

nathanfig 1y ago
Claude made this point while reviewing my blog for me: the mechanization of farms created a whole lot more specialization of roles. The person editing CAD diagrams of next year's combine harvester may not be a farmer strictly speaking, but farming is still where their livelihood comes from.
- swader999 1y ago
  Land is scarce though. The amount of software work that needs doing might not be, it could be infinite or probably more tied to electrical capacity.
- deleted 1y ago
  [deleted]
- dredmorbius 1y ago
  Strictly speaking, farming is where all our livelihoods come from, in the greatest part. We're all living off the surplus value of food production. (Also of other food, energy, and materials sourcing: fishing, forestry, mining, etc.) This was the insight of the French economist François Quesnay in his Tableau économique, foundation of the Physiocratic school of economics.
  - eru 1y ago
    You might find https://en.wikipedia.org/wiki/Margarine#Coal_butter https://en.wikipedia.org/wiki/Margarine#Coal_butter fascinating. > Strictly speaking, farming is where all our livelihoods come from, in the greatest part. We're all living off the surplus value of food production. I don't think farming is special here, because food isn't special. You could make exactly the same argument for water (or even air) instead of food, and all of a sudden all our livelihoods would derive ultimately from the local municipal waterworks. Whether that's a reductio ad absurdum of the original argument, or a valuable new perspective on the local waterworks is left as an exercise to the reader.