7 ms·

You're joking but it's true. I'm sure you know that. SQL had similar claims... Declarative, say what you need and the computer will do for you. Also written in

You're joking but it's true. I'm sure you know that. SQL had similar claims... Declarative, say what you need and the computer will do for you. Also written in English.

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.
- 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.
veqq 1y ago
Er, have you heard of datalog or Prolog? Declarative programming really does work. SQL was just... Botched.
- glimshe 1y ago
  Yes. And I think SQL is actually pretty good for what it does. My point, as the parent's (I suppose) is that we've heard this "XYZ, which uses natural language, will kill software development" before.
- sanderjd 1y ago
  I think SQL is better than datalog. I suspect this is one of those opinions that may be somewhat outside consensus on a forum like HN, but is strongly within the consensus more broadly.
  - aeonik 1y ago
    I like both, they excel at different things. SQL is pretty horrifying when you start getting tree structures or recursive structures. While Datalog handles those like a champ. SQL is really nice for columnar data, and it's well supported almost everywhere. Though Datalog isn't half bad at columnar data either.
    - sanderjd 1y ago
      Yeah. I think you and I have the same opinions about this :) I like SQL more when working with tabular data (especially for analytical use cases), but that has (thus far) dominated the kinds of work I've done.
dredmorbius 1y ago
I'd long ago (1990s-era) heard that the original intent was that office secretaries would write their own SQL queries. (I'd love for someone to substantiate or debunk this for me.)
- bazoom42 1y ago
  Early on, programming was considered secretarial work.
  - AdieuToLogic 1y ago
    > Early on, programming was considered secretarial work. Incorrect. Encoding a program was considered secretarial work, not the act of programming itself. Over time, "encoding" was shortened to "coding." This is why the industry term "coder" is a pejorative descriptor.
    - eru 1y ago
      > This is why the industry term "coder" is a pejorative descriptor. For some people some of the time. I don't think that's true in general.
    - 0points 1y ago
      > This is why the industry term "coder" is a pejorative descriptor. It is not.
      - brabel 1y ago
        It used to be widely seen as such. See for example Stallmanns latest post where he mentions that. Coder was not the same as programmer, it was the lesser half of the job. Nowadays the term has lost its original meaning.
- rsynnott 1y ago
  That's always the promise of these things; non-specialists will be able to program now! This has been going on since COBOL. The one case where it arguably worked out to some extent was spreadsheets.
kayodelycaon 1y ago
SQL and many DSLs (JIRA…) are actually used by plenty of non-technical users. Anyone who wants to build their own reports and do basic data analysis has sufficient incentive to learn it. They are very much the exception that proves the rule though.
rixed 1y ago
Or QBE, "Query By Exemple", that was another try by IBM to make a query language directly usable by anyone.
charlieyu1 1y ago
Don’t think the person was joking. It was literally the promise of COBOL

You're joking but it's true. I'm sure you know that. SQL had similar claims... Declarative, say what you need and the computer will do for you. Also written in English.

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.

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.

veqq 1y ago

Er, have you heard of datalog or Prolog? Declarative programming really does work. SQL was just... Botched.

glimshe 1y ago
Yes. And I think SQL is actually pretty good for what it does. My point, as the parent's (I suppose) is that we've heard this "XYZ, which uses natural language, will kill software development" before.
sanderjd 1y ago
I think SQL is better than datalog. I suspect this is one of those opinions that may be somewhat outside consensus on a forum like HN, but is strongly within the consensus more broadly.
- aeonik 1y ago
  I like both, they excel at different things. SQL is pretty horrifying when you start getting tree structures or recursive structures. While Datalog handles those like a champ. SQL is really nice for columnar data, and it's well supported almost everywhere. Though Datalog isn't half bad at columnar data either.
  - sanderjd 1y ago
    Yeah. I think you and I have the same opinions about this :) I like SQL more when working with tabular data (especially for analytical use cases), but that has (thus far) dominated the kinds of work I've done.

dredmorbius 1y ago

I'd long ago (1990s-era) heard that the original intent was that office secretaries would write their own SQL queries. (I'd love for someone to substantiate or debunk this for me.)

bazoom42 1y ago
Early on, programming was considered secretarial work.
- AdieuToLogic 1y ago
  > Early on, programming was considered secretarial work. Incorrect. Encoding a program was considered secretarial work, not the act of programming itself. Over time, "encoding" was shortened to "coding." This is why the industry term "coder" is a pejorative descriptor.
  - eru 1y ago
    > This is why the industry term "coder" is a pejorative descriptor. For some people some of the time. I don't think that's true in general.
  - 0points 1y ago
    > This is why the industry term "coder" is a pejorative descriptor. It is not.
    - brabel 1y ago
      It used to be widely seen as such. See for example Stallmanns latest post where he mentions that. Coder was not the same as programmer, it was the lesser half of the job. Nowadays the term has lost its original meaning.
rsynnott 1y ago
That's always the promise of these things; non-specialists will be able to program now! This has been going on since COBOL. The one case where it arguably worked out to some extent was spreadsheets.

kayodelycaon 1y ago

SQL and many DSLs (JIRA…) are actually used by plenty of non-technical users. Anyone who wants to build their own reports and do basic data analysis has sufficient incentive to learn it. They are very much the exception that proves the rule though.

rixed 1y ago

Or QBE, "Query By Exemple", that was another try by IBM to make a query language directly usable by anyone.

charlieyu1 1y ago

Don’t think the person was joking. It was literally the promise of COBOL