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

41–50 of 128 posts

Re: A Short Story About SQL’s Biggest Rival

#41

Post by setr »

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 look perfectly fine.

Every column being made NOT NULL is the only sane solution.

[0] https://databasetheory.org/sites/default/files/2018-05/03_pr...

Re: A Short Story About SQL’s Biggest Rival

#42

Post by cafard »

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.

Re: A Short Story About SQL’s Biggest Rival

#43

Post by ithkuil »

nine_k wrote: post #13
kmeisthax wrote: post #11

>If the world worked differently, we wouldn’t still be writing on QWERTY keyboards, or speaking English; technically superior alternatives like Dvorak and Esperanto would have taken over. Bad metaphor: There is no evidence for Dvorak's technical superiority to QWERTY, neither is there for Esperanto over other languages.

Esperanto is similar to a bunch of Roman languages widespread in Europe. One can see it as an attempt to collect them back into a common "Latin 2.0". Outside Western Europe, Esperanto makes rather little sense. It's highly regular, which is nice — but, say, Japanese is also highly regular.

Yes it's based off european languages; it was designed in a time when removing barriers from neighboring countries in a culturally very fragmented continent was perceived of higher practical value than creating a pan-human language; intercontinental travel wasn't yet as commonplace as now, yet many european countries had different cultures living within the boundaries of the same states and usually members of the majority culture were privileged as a result; there was hope (espero in esperanto) that people could forget about differences among them and see what they have in common.

Today we can be tempted to frame it as european chauvinism, but that's just because of our expanded horizons as a global society. People who believes in esperanto in the early days would likely share the same feeling now

Re: A Short Story About SQL’s Biggest Rival

#44

Post by cheschire »

lisper wrote: post #39
cafard wrote: post #38

"Mike Stonebraker of Ingres didn’t even bother to show up at the committee meeting to make the (quite strong) case for adopting QUEL because he was ideologically opposed to setting technology standards. It was the behavior of an intellectually arrogant academic rather than a prudent businessman protecting the interests of his company." Some might call the behavior principled, rather than arrogant.

Those are not mutually exclusive. (One could add "foolish" and "short-sighted" to the list of potentially compatible adjectives.)

And RMS being a good example of a principled and arrogant man that was neither foolish nor short sighted.

Re: A Short Story About SQL’s Biggest Rival

#45

Post by geophile »

wenc wrote: post #9
geophile wrote: post #2

Dupe: https://news.ycombinator.com/item?id=24709031 As I said the last time this came around: The end of this isn't quite right. The Postgres project started in 1986. I don't recall what language it used, QUEL perhaps, but it wasn't SQL. SQL support was added between 1994 and 1996, and that's when PostgreSQL was born.

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.

Re: A Short Story About SQL’s Biggest Rival

#46

Post by didibus »

alquemist wrote: post #30

> … The language (SQL) is not very composable. This is a fact that most SQL users are not aware of. The relational algebra that SQL is based on is absolutely composable but SQL is not due to the inherent limitation of the language (as it was designed to be natural language-like). When you write "select x from a where z", you are actually building something along the lines of "from a" => "where z" => "select x" in the…

This argues that composability is the most important consideration of a domain specific language. But I think, as proved by SQL taking over, the UX is more important. Any programming language must consider the programmer and its humanity and natural way of thinking and reasoning to win in getting the most adoption and mindshare. Usability does matter as the user of any programming language is a human being.

Was QUEL also more usable and natural to people? As well as being more amenable to composition?

Re: A Short Story About SQL’s Biggest Rival

#47

Post by eska »

mijamo wrote: post #20
thaumasiotes wrote: post #15

Earlier quoted context omitted.

> 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.

Esperanto is not a romance language. It incorporates elements from most european languages families (balto-slavic, germanic, romance), and the grammar is most particularly inspired by slavic languages. And it was pretty much a goal of its creator to be both familiar and foreign for different european language families, as he had experienced division in Poland between speakers of those different families and wanted to…

We're still ignoring the entire Asian and African continents then, though.

Re: A Short Story About SQL’s Biggest Rival

#48

Post by cbsmith »

k1t wrote: post #18
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…

> QWERTY was intentionally designed to avoid jams Minor quibble that this is not true (or at least strongly disputed). https://www.smithsonianmag.com/arts-culture/fact-of-fiction-...

I'm pretty sure the author was referring to the lore, regardless of what the truth might be. Otherwise they'd have had to present a much more detailed explanation.

Re: A Short Story About SQL’s Biggest Rival

#49

Post by cbsmith »

eska wrote: post #47
mijamo wrote: post #20

Earlier quoted context omitted.

Esperanto is not a romance language. It incorporates elements from most european languages families (balto-slavic, germanic, romance), and the grammar is most particularly inspired by slavic languages. And it was pretty much a goal of its creator to be both familiar and foreign for different european language families, as he had experienced division in Poland between speakers of those different families and wanted to…

We're still ignoring the entire Asian and African continents then, though.

Yes, in the design context of the creation of the language, that was not in scope, though there are arguments that it's word-formation mechanism bears more resemblance to Chinese than European languages.

Re: A Short Story About SQL’s Biggest Rival

#50

Post by nendroid »

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.

"attributes" are "generic" properties of relations.

So for example the union operator can take two different relations that have the same columns but different rows and create a new relation.

In this binary operation that takes two different relations.... the attributes of one relation (the columns) is indeed the attributes of the other relation.

See here: https://www.geeksforgeeks.org/basic-operators-in-relational-...

Look for "union" in the link above.

>Union on two relations R1 and R2 can only be computed if R1 and R2 are union compatible (These two relation should have same number of attributes and corresponding attributes in two relations have same domain)

It's the same thing for unary operations like select. A select expression can operate on different relations providing that the relations have the relevant attributes.

Post reply on HN