Re: The tragedy of SQL - Mailing list pgsql-general

From Raymond Brinzer
Subject Re: The tragedy of SQL
Date
Msg-id CANasJHk2MMEYXDF9q0WV0Ak8ByuroCwN7QvcuJZvdx5bsc8caA@mail.gmail.com
Whole thread Raw
In response to Re: The tragedy of SQL  (Rob Sargent <robjsargent@gmail.com>)
Responses Re: The tragedy of SQL  (Brian Dunavant <dunavant@gmail.com>)
List 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@gmail.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
writingin 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.
Theremay be bad (or at least inefficient) languages, but there are lots of bad programmers. 
> --
> Mike Nolan
> htfoot@gmail.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



pgsql-general by date:

Previous
From: Israel Brewster
Date:
Subject: Re: Fastest option to transfer db?
Next
From: Brian Dunavant
Date:
Subject: Re: The tragedy of SQL