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

From FWS Neil
Subject Re: The tragedy of SQL
Date
Msg-id 0772DCF3-D60F-4102-B031-9F7908718499@fairwindsoft.com
Whole thread Raw
In response to Re: The tragedy of SQL  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: The tragedy of SQL  (Michael Nolan <htfoot@gmail.com>)
Re: The tragedy of SQL  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: The tragedy of SQL  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-general


On Sep 15, 2021, at 2:44 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

On Tue, Sep 14, 2021 at 3:16 PM FWS Neil <neil@fairwindsoft.com> wrote:

On Sep 14, 2021, at 11:10 AM, Michael Nolan <htfoot@gmail.com> 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.

Yep, me too.  I would say that SQL has not achieved its design goals yet.  The original concept was to write what you want to achieve and have the server figure out the best way to get at it.

What people hate about SQL is that the programmer has to optimize SQL to get acceptable performance.  And the optimization is different for every implementation.  I think SQL has not hit its stride yet.  When the common $1000 server has 1024+ CPUs and 1+TB memory, and SQL implementations have adopted good multithreading architecture with access to 1024+ CPU dedicated AI engines, etc. a lot of the crap associated with performant SQL will go away.

At this point, I think it will be smart to strip out implementation details that have made it into the SQL syntax.  There will no longer be a need for it. This will make the SQL language simpler and easier to use, understand, and reason about.

I think you ought to recognize that many people on this list make
money directly from managing that complexity :-).


I did not intend to disparage anyone.  People, including myself, make money when they provide value and there is certainly value here.

But, I am not sure I understand your inference.  Are you saying (and I am not implying you are) that PostgreSQL does not progress in line with the original SQL goals of simplifying data access because people are making money off of the current complexity?

My only point was that SQL was originally conceived to free the programmer from implementation details.  Today, after 47 years, it still has not achieved that goal.  As computers get more powerful, of course, they will process more data, but they also have the option of moving more of the implementation decision making away from the programmer to let the machine figure out the best way to handle the request.  Therefore, I do not think SQL has hit its stride yet.

Programmers create a dozens of new languages every 10 years or so.  Only a few have stood the test of time.  SQL is one of those.  For all its faults, it still is amazingly powerful.

Neil

pgsql-general by date:

Previous
From: Gavin Flower
Date:
Subject: Re: Alter and move corresponding: was The tragedy of SQL
Next
From: Michael Nolan
Date:
Subject: Re: The tragedy of SQL