Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Short Story About SQL’s Biggest Rival

holistics.io

Post reply on HN
Print view View original

51–60 of 128 posts

Re: A Short Story About SQL’s Biggest Rival

#51

Post by wenc »

geophile wrote: post #45
wenc wrote: post #9

Earlier quoted context omitted.

I don't see the contradiction you mention. Stonebraker returned to Berkeley in 1985. The article doesn't say the Postgres project started in 1985. It says Stonebraker started a post-Ingres project then. The query language at that time might have been either QUEL or POSTQUEL [1] But the ending as it is written seems correct to me. [1] https://dsf.berkeley.edu/papers/ERL-M85-95.pdf

I didn't say that there was a contradiction. The paper is about QUEL vs. SQL. Given that Postgres/PostgreSQL is introduced, I would think that the initial use of QUEL (PostQUEL), and how and when and why it transitioned to SQL would be highly relevant. But the end of the paper is needlessly fuzzy on this topic.

This is the ending. Quote:

"The world has since standardised on SQL, and the dreams of an alternate history exists only in the heads of those who had a hand in the early database wars. It was simply a quirk of history that System R was built within IBM, the single most powerful company in the computer industry at the time; it was a quirk that the engineers who built System R came up with a fiddly language interface as an afterthought, and it was a quirk that IBM then took that language and pushed it to become a standard … one that has lasted till today.

Of course, there was a silver lining to the whole saga. Stonebraker had forked the Ingres codebase in 1982 to create his company. Defeated by the bruising database wars of the 80s, he returned to Berkeley in 1985, and started a post-Ingres database project. Naturally, he named that database post-gres — as in, after Ingres.

And thus PostgreSQL was born."

I was trying to figure what you meant. I think I have an inkling now -- let me know if this is correct. Your quibble is with the fact the implication here is that since SQL won, Stonebraker jumped on the SQL bandwagon and created a SQL database, when in fact, he didn't -- he merely created Postgres, which ran on QUEL and didn't have SQL until much later.

I think the author made a stylistic choice to omit that detail to drive home a point, but even so nothing was said that was non-factual.

Re: A Short Story About SQL’s Biggest Rival

#52

Post by magicalhippo »

nendroid wrote: post #33

The article talks about how SQL lacks composability. I would like to know everyones thoughts about this. This is a huge issue with programming in general not exclusive to SQL. Everyone would like to build programs that are modular and reusable but programming paradigms have been traveling in directions that prevent this from happening. Many people turn to design patterns or microservices to try to deal with this orga…

I've just learned SQL by doing. You're not including extensions here like stored procs and such right?

I have a lot of "where my_func(x, y, z) = 1" type where clauses, so seem that would do what you say, no?

Re: A Short Story About SQL’s Biggest Rival

#53

Post by cbsmith »

thaumasiotes wrote: post #15
cbsmith wrote: post #14

Earlier quoted context omitted.

I think the "technically superior" bit wasn't really the right choice of words. Esperanto isn't intended to be superior. It's value is on it being equally foreign yet approachable for all the salient parties and therefore a conceivable acceptable neutral turf for everyone to share. Ironically, the case for Dvorak keyboards is kind of the opposite: QWERTY was intentionally designed to avoid jams, which if anything bia…

> Esperanto isn't intended to be superior. It's value is on it being equally foreign yet approachable for all the salient parties and therefore a conceivable acceptable neutral turf for everyone to share. This was not even attempted; Esperanto is a Romance language. Unless you think the only salient parties are Spain, France, Portugal, Italy, and Latin America, this "value" does not exist and was not a goal.

The vocabulary is primarily from Romance languages, but the whole story is more complicated. From the Wikipedia page: "Esperanto's phonology, grammar, vocabulary, and semantics are based on the Indo-European languages spoken in Europe. The sound inventory is essentially Slavic, as is much of the semantics, whereas the vocabulary derives primarily from the Romance languages, with a lesser contribution from Germanic languages and minor contributions from Slavic languages and Greek. Pragmatics and other aspects of the language not specified by Zamenhof's original documents were influenced by the native languages of early authors, primarily Russian, Polish, German, and French. Paul Wexler proposes that Esperanto is relexified Yiddish, which he claims is in turn a relexified Slavic language,[72] though this model is not accepted by mainstream academics.[73]

Esperanto has been described as "a language lexically predominantly Romanic, morphologically intensively agglutinative, and to a certain degree isolating in character".[74] Typologically, Esperanto has prepositions and a pragmatic word order that by default is subject–verb–object. Adjectives can be freely placed before or after the nouns they modify, though placing them before the noun is more common. New words are formed through extensive prefixing and suffixing."

https://en.wikipedia.org/wiki/Esperanto

Re: A Short Story About SQL’s Biggest Rival

#54

Post by prostodata »

exabrial wrote: post #16

Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.

Here are some major issues [1]:

SQL’s shortcomings can be grouped into these categories:

- lack of proper orthogonality — SQL is hard to compose;

- lack of compactness — SQL is a large language;

- lack of consistency — SQL is inconsistent in syntax and semantics;

- poor system cohesion — SQL does not integrate well enough with application languages and protocols.

[1] We Can Do Better Than SQL: https://www.edgedb.com/blog/we-can-do-better-than-sql/

Re: A Short Story About SQL’s Biggest Rival

#55

Post by dragonwriter »

cafard wrote: post #42
nendroid wrote: post #33

The article talks about how SQL lacks composability. I would like to know everyones thoughts about this. This is a huge issue with programming in general not exclusive to SQL. Everyone would like to build programs that are modular and reusable but programming paradigms have been traveling in directions that prevent this from happening. Many people turn to design patterns or microservices to try to deal with this orga…

Is this really a SQL feature or a relational feature? The essence of the relational model is that names are known up front: an attribute of one relation is not an attribute of another.

> Is this really a SQL feature or a relational feature?

SQL.

There is no reason you couldn't have a composable implementaiton of relational logic.

> The essence of the relational model is that names are known up front

That every relation consist of tuples each member of which consists of a name, a type, and a value is part of the model, sure. That doesn't impose restrictions on composability.

> an attribute of one relation is not an attribute of another.

An attribute of one relation may well be an attribute of another.

There's no reason you couldn't have a relational language that let you store and reuse clauses.

Re: A Short Story About SQL’s Biggest Rival

#56

Post by geophile »

wenc wrote: post #51
geophile wrote: post #45

Earlier quoted context omitted.

I didn't say that there was a contradiction. The paper is about QUEL vs. SQL. Given that Postgres/PostgreSQL is introduced, I would think that the initial use of QUEL (PostQUEL), and how and when and why it transitioned to SQL would be highly relevant. But the end of the paper is needlessly fuzzy on this topic.

This is the ending. Quote: "The world has since standardised on SQL, and the dreams of an alternate history exists only in the heads of those who had a hand in the early database wars. It was simply a quirk of history that System R was built within IBM, the single most powerful company in the computer industry at the time; it was a quirk that the engineers who built System R came up with a fiddly language interface a…

The omission, combined with the context, leads the reader to make an incorrect conclusion.

    ... he returned to Berkeley in 1985, and started a post-
    Ingres database project.
That would be Postgres.

    Naturally, he named that database post-gres — as in, after Ingres.
He says it's Postgres.

    And thus PostgreSQL was born.
"thus" implies that the preceding discussion, about Postgres, describes the birth of PostgreSQL. Which it doesn't. At best, this is confusing, suggesting that Postgres = PostgreSQL. Postgres became PostgreSQL ten years later, once SQL was added, replacing PostQUEL. The elided details allow for different interpretations, including the wrong one, that SQL was there from the beginning. Also, the tone of the text you quoted suggests that Stonebraker learned his lesson, and just went to SQL for the Postgres project, which he definitely did not do.

Re: A Short Story About SQL’s Biggest Rival

#57

Post by exabrial »

setr wrote: post #41
exabrial wrote: post #16

Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.

My bigger concern regarding NULLs is that its a ternary logic shoved into a binary logic system, and it all invisibly becomes nonsense when your dataset has NULLs in it, and you don't explicitly address it WHERE col1 > col2 is wrong, and it'll break in terrible ways and in the face of negation + NULLs, everything falls apart[0], giving you both false positive and false negatives in your answerset, and everything will…

you're not wrong... Null by itself is sort of crazy in a binary system, but I see that as more a problem with binary representing reality rather than the other way around. It's a handy abstraction in that sense but a nightmare for systems level programming.

Re: A Short Story About SQL’s Biggest Rival

#58

Post by jhallenworld »

I don't like either syntax. Wikipedia has this example:

QUEL:

    range of E is EMPLOYEE
    retrieve into W
    (COMP = E.Salary / (E.Age - 18))
    where E.Name = "Jones"
SQL:

    select (e.salary / (e.age - 18)) as comp
    from employee as e
    where e.name = "Jones"
I would prefer an operator syntax that directly mimics relational algebra. Something like:

    w = employee(name == "Jones")[comp = salary / (age - 18)]
So () is "where", [] is "project" (choose or create columns) and you can use * for join and + for union. The result is a table with a column named comp.

Re: A Short Story About SQL’s Biggest Rival

#60

Post by wenc »

geophile wrote: post #56
wenc wrote: post #51

Earlier quoted context omitted.

This is the ending. Quote: "The world has since standardised on SQL, and the dreams of an alternate history exists only in the heads of those who had a hand in the early database wars. It was simply a quirk of history that System R was built within IBM, the single most powerful company in the computer industry at the time; it was a quirk that the engineers who built System R came up with a fiddly language interface a…

The omission, combined with the context, leads the reader to make an incorrect conclusion. ... he returned to Berkeley in 1985, and started a post- Ingres database project. That would be Postgres. Naturally, he named that database post-gres — as in, after Ingres. He says it's Postgres. And thus PostgreSQL was born. "thus" implies that the preceding discussion, about Postgres, describes the birth of PostgreSQL. Which…

I see what you're saying about that implication. I think the effects were indirect; SQL winning meant that Postgres, even though it started out supporting only POSTQUEL, had to evolve to eventually supporting SQL -- though you are correct that the cause-effect was not as direct and as inexorable as might have been implied in the prose.

I personally think eliding details was artistic license to make the prose flow better without bringing in ancillary details, but that's just me.

Stonebraker did eventually change his mind about SQL however -- if you've watched any of his recent talks he's of the opinion that most query languages will eventually and inexorably converge to some variant of SQL. (he was wrong about Mongo inventing a SQL-like query language, but that's what his philosophical commitments look like these days)

Post reply on HN