Re: The tragedy of SQL

From: Raymond Brinzer <ray(dot)brinzer(at)gmail(dot)com>
To: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: The tragedy of SQL
Date: 2021-09-14 17:53:52
Message-ID: CANasJHk2MMEYXDF9q0WV0Ak8ByuroCwN7QvcuJZvdx5bsc8caA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

This is a subject which is important to me, but I find discussing it
often goes poorly. Most people (not necessarily those on this list)
don't distinguish between SQL and the relational model. When you
criticize SQL the language, people tend to defend relational
databases; when you praise relational databases, people have a
visceral reaction to SQL.

There also seems to be a divide between people who use languages to
express their thoughts, with the expectation that their thoughts will
be implemented, and those who regard a language merely as an interface
for manipulating an underlying system. I think there's a lot of good
to be said of workmen who get the job done without complaining about
their tools. But in the big picture, it seems to me that all the
progress we've made with computers has been a matter of improving the
toolchain. The CPU is, after all, an underlying system, and there's
nothing you couldn't get done with assembler (or just machine code).
If you were smart enough, and had enough time.

The problem is, tools tend to impose an "IQ tax": thought spent on
managing the tool is thought not spent on solving the problem. I tend
to be stingy about paying that; I'm not smart enough, and I don't have
enough time.

Merlin's point about algebraic syntax fits well, here. Once you're
used to it, (x ∩ y) imposes less of a cognitive load than SELECT *
FROM x INTERSECT SELECT * FROM y. You can see how that scales, as
expressions get larger. There's a reason we no longer try to make
programming languages look like English, or other natural languages,
however reasonable it might have seemed in the 1970s.

And then there are very simple things I can't say reasonably, like
"SELECT * EXCEPT col_3", or "Tell me how many nulls are in each
column." Naturally, I can get these done; but the gap between what
was required to explain the goal and what is required to accomplish it
is much too large.

So, the affection I have for SQL is due to it being a gateway to a
great idea; my frustration is that it's a bottleneck in getting to
that same idea.

On Tue, Sep 14, 2021 at 12:20 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
>
> On 9/14/21 10:10 AM, Michael Nolan wrote:
>
> I started programming in 1967, and over the last 50+ years I've programmed in more languages than I would want to list. I spent a decade writing in FORTRAN on a GA 18/30 (essentially a clone of the IBM 1130) with limited memory space, so you had to write EFFICIENT code, something that is a bit of a lost art these days. I also spent a decade writing in COBOL.
>
> I've not found many tasks that I couldn't find a way to write in whatever language I had available to write it in. There may be bad (or at least inefficient) languages, but there are lots of bad programmers.
> --
> Mike Nolan
> htfoot(at)gmail(dot)com
>
> OK, I'm maybe responsible for this thread turning into a diatribe. I shouted at OP 'cause he shouted at us. My mistake, and I apologize.
> I'm probably closer to Mike's "bad programmers" than I would care to admit but fully believe software is a "people problem" more than most of us realize.

--
Ray Brinzer

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Brian Dunavant 2021-09-14 18:41:22 Re: The tragedy of SQL
Previous Message Israel Brewster 2021-09-14 17:03:22 Re: Fastest option to transfer db?