Re: The tragedy of SQL

On Fri, Sep 17, 2021 at 1:13 PM Benedict Holland < benedict.m.holl...@gmail.com> wrote: > I don't get why there are so many programming languages out there. C is > virtually perfect. > Oh my. Even its creators didn't believe this, and that was decades ago. Use after free. Dangling pointers. No ar

Re: The tragedy of SQL

I love how we would admonish sql but love lisp. There isn't a perfect language. SQL is fine. C is damn good. C++ is impossible, Java is C++ but simple, Python is a C wrapper. God help us if we settled on Fortran. We would still have single core processors. Lisp at least allowed multithreading but i

Re: The tragedy of SQL

On 17/09/21 23:49, Raymond Brinzer wrote: On Tue, Sep 14, 2021 at 9:06 AM Merlin Moncure wrote: I've long thought that there is more algebraic type syntax sitting underneath SQL yearning to get out. I wanted to come back to this, because I've been looking to take a single problem (from my pers

Re: The tragedy of SQL

On Fri, Sep 17, 2021 at 06:49 Raymond Brinzer wrote: On Tue, Sep 14, 2021 at 9:06 AM Merlin Moncure wrote: > > I've long thought that there is more algebraic type syntax sitting > > underneath SQL yearning to get out. ... > Now, if this sort of thing suits the way you think, I say, "Great!" > I'm

Re: The tragedy of SQL

On Fri, Sep 17, 2021 at 7:49 AM Raymond Brinzer wrote: > Now, if this sort of thing suits the way you think, I say, "Great!" > I'm glad you have a language which suits you. Reading this over, I realized I should have been more clear: I mean "you" generally. I liked your comment about algebraic

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 9:06 AM Merlin Moncure wrote: > I've long thought that there is more algebraic type syntax sitting > underneath SQL yearning to get out. I wanted to come back to this, because I've been looking to take a single problem (from my perspective) and explain it concisely. Your

Re: The tragedy of SQL

On Wed, Sep 15, 2021 at 2:46 AM Julien Rouhaud wrote: > I agree, and actually sent a patch some time ago to allow usage of > third-party parser(s). They can coexist with the core one, meaning > that you can (if you write your parser this way) use both languages, > even in a multi-query string. S

Re: The tragedy of SQL

is when people make statements like the “tragedy of SQL” or anything else that equates SQL with the concept of a RDBMS. The two are not the same thing. Let us not forget that SQL is an acronym for Structured Query Language and it is indeed just that: a language and a tool to be used in

Re: The tragedy of SQL

On 9/16/21 6:29 PM, Guyren Howe wrote: [snip] Missing my original point here. The set theory is the _point_. SQL is a gargantuan distraction from using it efficiently. Imagine if COBOL was the only widely-available programming language with functions. You might use it, because functions are re

Re: The tragedy of SQL

On 9/16/21 3:21 PM, Gavin Flower wrote: On 17/09/21 04:26, Michael Nolan wrote: In the same 1971 seminar where we studied Algol-68, we had to read and write a short paper on the 1970 Codd paper on relational  theory, which had only been out for about a year.  The professor running the seminar

Re: The tragedy of SQL

On 17/09/21 11:29, Guyren Howe wrote: [...] The set theory is the _point_. SQL is a gargantuan distraction from using it efficiently. Imagine if COBOL was the only widely-available programming language with functions. You might use it, because functions are really great abstraction for progra

Re: Alter and move corresponding: was The tragedy of SQL

On 17/09/21 11:22, Rob Sargent wrote: As far as alter, in 1981, before I became a programmer, I asked my Cobol Programmer friend if there was anything you could put in a program that would get you fired. He said yes, the alter statement :-). In my 3 semesters of Cobol, I never once used the Alte

Re: The tragedy of SQL

On 9/16/21 19:29, Guyren Howe wrote: Missing my original point here. The set theory is the _point_. SQL is a gargantuan distraction from using it efficiently. Imagine if COBOL was the only widely-available programming language with functions. You might use it, because functions are really gr

Re: The tragedy of SQL

Missing my original point here. The set theory is the _point_. SQL is a gargantuan distraction from using it efficiently. Imagine if COBOL was the only widely-available programming language with functions. You might use it, because functions are really great abstraction for programming. That

Re: The tragedy of SQL

On Sep 16, 2021, at 7:31 , Merlin Moncure wrote: > > On Wed, Sep 15, 2021 at 7:31 PM FWS Neil wrote: >> On Sep 15, 2021, at 2:44 PM, Merlin Moncure wrote: >>> I think you ought to recognize that many people on this list make >>> money directly from managing that complexity :-). >> >> I did not

Re: Alter and move corresponding: was The tragedy of SQL

As far as alter, in 1981, before I became a programmer, I asked my Cobol Programmer friend if there was anything you could put in a program that would get you fired. He said yes, the alter statement :-). In my 3 semesters of Cobol, I never once used the Alter statement. [...] I was very proud

Re: Alter and move corresponding: was The tragedy of SQL

On 16/09/21 04:52, Steve Litt wrote: Gavin Flower said on Wed, 15 Sep 2021 13:49:39 +1200 Hi Michael, [snip] COBOL has strange verbs like 'move corresponding' that could accomplish complicated tasks in a few lines but you have to be careful that you knew what you were asking for! In our sit

Re: The tragedy of SQL

On 17/09/21 04:26, Michael Nolan wrote: In the same 1971 seminar where we studied Algol-68, we had to read and write a short paper on the 1970 Codd paper on relational  theory, which had only been out for about a year.  The professor running the seminar noted that Codd proved that the relationa

Re: Alter and move corresponding: was The tragedy of SQL

One of the grad students in the computer center had a sign on his wall: God is real, but Man is only an integer. -- Mike Nolan

Re: The tragedy of SQL

In the same 1971 seminar where we studied Algol-68, we had to read and write a short paper on the 1970 Codd paper on relational theory, which had only been out for about a year. The professor running the seminar noted that Codd proved that the relational model worked, but didn't guarantee that it

Re: The tragedy of SQL

On Wed, Sep 15, 2021 at 7:31 PM FWS Neil wrote: > On Sep 15, 2021, at 2:44 PM, Merlin Moncure wrote: > > 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, mak

Re: The tragedy of SQL

Em 15/09/2021 21:55, Adrian Klaver escreveu: On 9/15/21 5:30 PM, FWS Neil wrote: On Sep 15, 2021, at 2:44 PM, Merlin Moncure > wrote: I think you ought to recognize that many people on this list make money directly from managing that complexity :-). I did

Re: Alter and move corresponding: was The tragedy of SQL

On 16 Sep 2021, at 9:31, Gavin Flower wrote: > would assign the value of 42 to x. > Which brings up another topic, e.g., https://news.mit.edu/2019/answer-life-universe-and-everything-sum-three-cubes-mathematics-0910 > Never tried it, I now wish I had! > You could see if it’s accurately emulated

Re: The tragedy of SQL

On 9/15/21 5:30 PM, FWS Neil wrote: On Sep 15, 2021, at 2:44 PM, Merlin Moncure > wrote: 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, includin

Re: The tragedy of SQL

On Wed, Sep 15, 2021 at 7:31 PM FWS Neil wrote: > > 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 > www.fairwindsoft.com > > Dennis Ritchie was giv

Re: The tragedy of SQL

> On Sep 15, 2021, at 2:44 PM, Merlin Moncure wrote: > > On Tue, Sep 14, 2021 at 3:16 PM FWS Neil > wrote: >> >>> On Sep 14, 2021, at 11:10 AM, Michael Nolan wrote: >>> >>> I started programming in 1967, and over the last 50+ years I've programmed >>> in more

Re: Alter and move corresponding: was The tragedy of SQL

On 16/09/21 05:47, Michael Nolan wrote: When I was working at the help desk at the computer center as an undergrad, the professor in charge of that group used to give us interesting little language tests for things we needed to watch out for, especially with beginning programmers. One of his

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 3:16 PM FWS Neil wrote: > > > On Sep 14, 2021, at 11: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 (es

Re: Alter and move corresponding: was The tragedy of SQL

On 9/15/21 11:52 AM, Steve Litt wrote: Gavin Flower said on Wed, 15 Sep 2021 13:49:39 +1200 Hi Michael, [snip] COBOL has strange verbs like 'move corresponding' that could accomplish complicated tasks in a few lines but you have to be careful that you knew what you were asking for! MOVE CO

Re: Alter and move corresponding: was The tragedy of SQL

When I was working at the help desk at the computer center as an undergrad, the professor in charge of that group used to give us interesting little language tests for things we needed to watch out for, especially with beginning programmers. One of his favorite ploys was to use the EQUIVALENCE fun

Alter and move corresponding: was The tragedy of SQL

Gavin Flower said on Wed, 15 Sep 2021 13:49:39 +1200 >Hi Michael, [snip] >> >> COBOL has strange verbs like 'move corresponding' that could >> accomplish complicated tasks in a few lines but you have to be >> careful that you knew what you were asking for! > >In our site that was banned as be

Re: SQL queries as sets: was The tragedy of SQL

On Wed, Sep 15, 2021 at 12:55 AM Steve Litt wrote: > Rich, could you please elaborate on SQL queries being based on sets? I > never thought of it that way, and would like to hear your related > thoughts. I'll take a crack at this. Going through the setup will require a little patience, but I thi

Re: SQL queries as sets: was The tragedy of SQL

On Wed, 15 Sep 2021, Steve Litt wrote: Rich, could you please elaborate on SQL queries being based on sets? I never thought of it that way, and would like to hear your related thoughts. SteveT, In the 1980s, when there were computer magazines such as Byte and Database Administrator (among man

Re: SQL queries as sets: was The tragedy of SQL

> > Rich, could you please elaborate on SQL queries being based on sets? > I > never thought of it that way, and would like to hear your related > thoughts. > When Codd & Date elaborated the relational model, it was based on set theory. You have sets of data. Is there a relationship between the

Re: SQL queries as sets: was The tragedy of SQL

tt Sent: Wednesday, September 15, 2021 16:54 To: pgsql-general@lists.postgresql.org Subject: SQL queries as sets: was The tragedy of SQL Rich Shepard said on Tue, 14 Sep 2021 05:49:07 -0700 (PDT) >On Mon, 13 Sep 2021, Guyren Howe wrote: > >> They are making a decent decision. SQL is a

Re: The tragedy of SQL

On Wed, Sep 15, 2021 at 8:31 AM Raymond Brinzer wrote: > > So, on a practical note: I'd like it if PostgreSQL supported > alternate languages for queries, as it does for stored procedures. I agree, and actually sent a patch some time ago to allow usage of third-party parser(s). They can coexist

Re: SQL queries as sets: was The tragedy of SQL

Oh, yeah, wow. Big topic. My original post in the series is in significant part about how SQL hides this sort of thing from you. A table is a set:  a set of true facts, all having the same structure, so you can operate on all of them with any operation on the individual rows. Multiple tables,

SQL queries as sets: was The tragedy of SQL

Rich Shepard said on Tue, 14 Sep 2021 05:49:07 -0700 (PDT) >On Mon, 13 Sep 2021, Guyren Howe wrote: > >> They are making a decent decision. SQL is a *fucking terrible* >> language, which I don’t blame them for not wanting to learn. > >>> SQL is not the problem. Problem are the devs. I love SQL.

Re: The tragedy of SQL

Hi Michael, Appropriate comments interspersed below. I'm happy writing SQL and moderately competent using it.  But like all the languages I've used, without exception, it has its pain points. Cheers, Gavin On 15/09/21 11:25, Michael Nolan wrote: Of all the languages I wrote in, I think SNOB

Re: The tragedy of SQL

On 9/14/21 12:51 PM, Mladen Gogala wrote: Replies in-line On 9/14/21 01:51, Guyren Howe wrote: They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn. Based on what criteria? The whole industry, programming languages, inf

Re: The tragedy of SQL

So, on a practical note: I'd like it if PostgreSQL supported alternate languages for queries, as it does for stored procedures. Yes, I know this will strike some of you as an abomination. I think we can take that part as read. ;-) I see two ways of going about this. The quick & dirty way woul

Re: The tragedy of SQL

Of all the languages I wrote in, I think SNOBOL was the most fun to write in, and LISP the least fun. Control Data assembler language programming was probably the most precise, because you could crash the OS with a single mis-placed character, something I did more than once. In a graduate-level c

Re: The tragedy of SQL

On 15/09/21 10:30, Peter J. Holzer wrote: On 2021-09-14 16:51:39 -0400, Mladen Gogala wrote: As software engineers, we are very much opposed to poetry, especially those among us using Perl. When I learned Perl, Perl poetry was a real thing! hp Perl is too verbose, use APL!  See: htt

Re: The tragedy of SQL

It is kind of a purists fallacy. Point being if you could just write ASM code it would be the best. When in reality, a database is used not because it is the best technical database, but is used by many people. Something that other developers can pickup and use without reading a 200 page manual an

Re: The tragedy of SQL

On 15/09/21 04:10, 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

Re: The tragedy of SQL

On 2021-09-14 16:51:39 -0400, Mladen Gogala wrote: > As software engineers, we are very much opposed to poetry, especially > those among us using Perl. When I learned Perl, Perl poetry was a real thing! hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) |

Re: The tragedy of SQL

On 2021-09-14 17:01:40 -0400, Mladen Gogala wrote: > On 9/14/21 15:57, Guyren Howe wrote: > > Verbosity. Redundancy. Lack of orthogonality. Resemblance to English. > > Verbosity is a feature, as well as the resemblance to English. The language > is meant to be understood by accountants. Once upon

Re: The tragedy of SQL

On 9/14/21 15:57, Guyren Howe wrote: Verbosity. Redundancy. Lack of orthogonality. Resemblance to English. Verbosity is a feature, as well as the resemblance to English. The language is meant to be understood by accountants. Once upon a time people were using something called "COmmon Busine

Re: The tragedy of SQL

On 9/14/21 16:07, Raymond Brinzer wrote: By analogy: Arabic and Roman numerals both describe the natural numbers. Hence, they have the same mathematical properties. Spending a little time doing algebra with Roman numerals should convince anyone, however, that how you express a concept matter

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 4:16 PM FWS Neil wrote: > What people hate about SQL is that the programmer has to optimize SQL to get > acceptable performance. Oh, no, that's just one thing. :-) And to be fair, it's a hard problem. We're asking for an optimizer, written for databases generally, to o

Re: The tragedy of SQL

> On Sep 14, 2021, at 11: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

Re: The tragedy of SQL

Exactly. SQL is the roman numerals of relational databases. On Sep 14, 2021, 13:08 -0700, Raymond Brinzer , wrote: > On Tue, Sep 14, 2021 at 3:58 PM Guyren Howe wrote: > > You’re confusing SQL with the relational model. Datalog and Quel and > > Tutorial D and other database languages and systems

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 3:58 PM Guyren Howe wrote: > You’re confusing SQL with the relational model. Datalog and Quel and Tutorial > D and other database languages and systems can and did provide those features > also. By analogy: Arabic and Roman numerals both describe the natural numbers. H

Re: The tragedy of SQL

The big advantage for SQL is that it has remained relatively constant and universal for ~40 years. There is effectively one major relational database language that you need to learn and that is that. Once you learn it you can transport your knowledge to nearly every other relational database enviro

Re: The tragedy of SQL

On 9/14/21 1:53 PM, Mladen Gogala wrote: On 9/14/21 02:18, Rob Sargent wrote: All languages are fucking terrible. I like English. It's not very complex and it allows me to express myself very well. You should see my native tongue, Croatian language, from the group of Slavic languages. It's

Re: The tragedy of SQL

On Sep 14, 2021, 12:51 -0700, Mladen Gogala , wrote: > Replies in-line > On 9/14/21 01:51, Guyren Howe wrote: > > They are making a decent decision. SQL is a *fucking terrible* language, > > which I don’t blame them for not wanting to learn. > Based on what criteria? Verbosity. Redundancy. Lack of

Re: The tragedy of SQL

On 9/14/21 02:18, Rob Sargent wrote: All languages are fucking terrible. I like English. It's not very complex and it allows me to express myself very well. You should see my native tongue, Croatian language, from the group of Slavic languages. It's fucking terrible. -- Mladen Gogala Data

Re: The tragedy of SQL

Replies in-line On 9/14/21 01:51, Guyren Howe wrote: They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn. Based on what criteria? The whole industry, programming languages, infrastructure, everything would have develop

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 2:41 PM Brian Dunavant wrote: > I have the opposite perspective. As a dev/manager, SQL is much more powerful > at getting data storage from abstract concept, into a usable structure, than > any programming language I've had the (mis)fortune of using. I've long > sinc

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 1:54 PM Raymond Brinzer wrote: > > 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. > > I have the opposite perspective. As a dev/manager, SQL is much more powerful at

Re: The tragedy of SQL

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 relatio

Re: The tragedy of SQL

I didn't start in 1967, but 1984, I'm in agreement with the bad programmers premise. Since the beginning there have always been lots of languages. It is my opinion, the more languages and concepts you know the better your success on the project. Heck I didn't use triggers till late 90's, funn

Re: The tragedy of SQL

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 wri

Re: The tragedy of SQL

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

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 9:01 AM Rob Sargent wrote: > > ORMs a function of poor development culture and vendor advocacy, not > > the fault of SQL. If developers don't understand or are unwilling to > > use joins in language A, they won't in language B either. > > Back in the day, within IBM there w

Re: The tragedy of SQL

There was also QUEL. The original language for Ingress out of UCB. > On 09/14/2021 9:51 AM David Goodenough > wrote: > > > On Tuesday, 14 September 2021 14:06:13 BST Merlin Moncure wrote: > > On Tue, Sep 14, 2021 at 12:32 AM Guyren Howe wrote: > > > If I had $5 mill

Re: The tragedy of SQL

> ORMs a function of poor development culture and vendor advocacy, not > the fault of SQL. If developers don't understand or are unwilling to > use joins in language A, they won't in language B either. > > merlin Back in the day, within IBM there were two separate relational databases.  Sy

Re: The tragedy of SQL

On Tuesday, 14 September 2021 14:06:13 BST Merlin Moncure wrote: > On Tue, Sep 14, 2021 at 12:32 AM Guyren Howe wrote: > > If I had $5 million to invest in a startup, I would hire as many of the > > core Postgres devs as I could to make a new database with all the > > sophistication of Postgres bu

Re: The tragedy of SQL

On Tue, Sep 14, 2021 at 12:32 AM Guyren Howe wrote: > If I had $5 million to invest in a startup, I would hire as many of the core > Postgres devs as I could to make a new database with all the sophistication > of Postgres but based on Datalog (or something similar). (Or maybe add > Datalog to

Re: The tragedy of SQL

> > As a non-SQL expert who's used postgres since 1997 I've come to believe the > basic issue is that SQL is based on sets, neither procedural or object > oriented. Few people think in sets so they try to fit SQL into what they > know rather than understand the how sets work. > Yes, that's 100% co

Re: The tragedy of SQL

On Mon, 13 Sep 2021, Guyren Howe wrote: They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn. SQL is not the problem. Problem are the devs. I love SQL. I hate orms. The problem with databases is people refuse to treat it as

Re: The tragedy of SQL

Is it possible that this is mainly an emotional discussion? Raymond Brinzer schreef op di 14-09-2021 om 02:39 [-0400]: > Many languages are awesome. I'm always astonished at what great > things people have come up with, over the years; it's been a > wonderfully fertile field. We would certainly

Re: The tragedy of SQL

Many languages are awesome. I'm always astonished at what great things people have come up with, over the years; it's been a wonderfully fertile field. We would certainly not be better off if we'd just buckled down, and used COBOL and FORTRAN... or even relatively good languages like C, APL, and

Re: The tragedy of SQL

On 9/13/21 11:51 PM, Guyren Howe wrote: They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn. The whole industry, programming languages, infrastructure, everything would have developed differently if relations were a natural

Re: The tragedy of SQL

They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn. The whole industry, programming languages, infrastructure, everything would have developed differently if relations were a natural, pleasurable thing to use in any program

The tragedy of SQL

A fun philosophical discussion. I am no fan of “worse is better”, and particularly its poster child, SQL. The world’s economic output would be substantially higher (5%?) if our industry had settled on almost anything other than SQL for relational databases. So much of the design of *almost ever