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

61–70 of 128 posts

Re: A Short Story About SQL’s Biggest Rival

#61

Post by edjroot »

bsder wrote: post #35
tbenst wrote: post #19

Earlier quoted context omitted.

Dvorak is 25% more efficient than Qwerty using some very reasonable calculations: http://mkweb.bcgsc.ca/carpalx/?dvorak

And by some other measures (hand alternation of fingers) Dvorak is less efficient. QWERTY isn't as bad as people make it out to be, and Dvorak isn't as good as people make it out to be. There are keyboard configurations that are better than both, but nobody uses them because you'll never be able to use anybody else's keyboard.

> nobody uses them because you'll never be able to use anybody else's keyboard

I doubt that's the main reason, and it may be unwarranted as I say below. Personally, I thought it would take too long for me to be able to type as fast as in QWERTY. Fortunately, I was wrong about that too.

I learned the QGMLW optimized layout from Carpalx (linked above) about a year ago. I trained on https://keybr.com and then on https://typeracer.com for a few days and in less than a week I reached 70wpm. I stopped training shortly after and now I can usually reach 90-100wpm. Not particularly fast, but I'm not any faster in QWERTY, and I believe I could get faster if I trained more.

Even though I almost never type in QWERTY anymore, when I do I'm still just as fast as I used to be. I never learned to type in QWERTY "the right way", though, and I suppose this is actually what keeps me from confusing the two "modes". Whenever I try to keep my fingers on their "appropriate" keys (like a properly trained typist would), it's like my brain switches to "Carpalx mode" (since I did make an effort to use the right finger positioning to learn it). It's kinda like switching between thinking in my native language and English - I can think in both, but it doesn't "feel" the same, and I'm more likely to confuse the two where they overlap more. Pretty interesting, really.

Re: A Short Story About SQL’s Biggest Rival

#62

Post by setr »

exabrial wrote: post #57
setr wrote: post #41

Earlier quoted context omitted.

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.

The concept is useful, the implementation is not. You really just want better ergonomics for enums, and encode the many ways NULL is meant to mean that way

Re: A Short Story About SQL’s Biggest Rival

#63

Post by greenshackle2 »

edjroot wrote: post #61
bsder wrote: post #35

Earlier quoted context omitted.

And by some other measures (hand alternation of fingers) Dvorak is less efficient. QWERTY isn't as bad as people make it out to be, and Dvorak isn't as good as people make it out to be. There are keyboard configurations that are better than both, but nobody uses them because you'll never be able to use anybody else's keyboard.

> nobody uses them because you'll never be able to use anybody else's keyboard I doubt that's the main reason, and it may be unwarranted as I say below. Personally, I thought it would take too long for me to be able to type as fast as in QWERTY. Fortunately, I was wrong about that too. I learned the QGMLW optimized layout from Carpalx (linked above) about a year ago. I trained on https://keybr.com and then on https:/…

Yeah I did the same thing but I learned colemak. I never learned to touch-type qwerty, when I learned touch-typing I switched to colemak. I feel like it made things easier as I didn't have bad habits to fall back on.

I can still type qwerty but I'm not very fast at it (I never was).

Re: A Short Story About SQL’s Biggest Rival

#64

Post by titanomachy »

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.

In retrospect, standards turned out to be rather important.

Re: A Short Story About SQL’s Biggest Rival

#65

Post by bawolff »

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 don't really feel like composability/modularity is all that important in SQL.

I want modularity in programs because they are large, and without proper abstraction, impossible to manage.

SQL queries are generally really short. Rarely more than a few lines (might be different for people doing ad-hoc analysis instead of making a db backed application). I don't need modularity for a program that is only a few lines long.

The lack of really natural integration into modern day programming languages (and data model mismatches) is a much bigger issue imo

Re: A Short Story About SQL’s Biggest Rival

#68

Post by brian_herman »

jhallenworld wrote: post #58

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 "p…

That sounds like a cool language.

Re: A Short Story About SQL’s Biggest Rival

#69

Post by alquemist »

didibus wrote: post #46
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…

There are a handful of examples on Wikipedia: https://en.wikipedia.org/wiki/QUEL_query_languages. One example:

    retrieve (a=count(y.i by y.d where y.str = "ii*" or y.str = "foo"), b=max(count(y.i by y.d)))
Not a particularly clear 'jumps at you' obvious semantic:

* Are a and b aggregation functions or window functions? If aggregations, how do they compose if the 'by' scopes are different?

* What does max(count(... by ...)) mean? What is the aggregation (window?) scope of max?

* How would an outer where clause compose? What is the evaluation order?

Re: A Short Story About SQL’s Biggest Rival

#70

Post by wenc »

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.

I consider myself a fan of SQL, but my nitpick is more around named calculated columns. For instance:

    SELECT AVG(col1) OVER (PARTITION BY col2) AS partcol1
    FROM tbl
    WHERE AVG(col1) OVER (PARTITION BY col2) > 10.0
I wish I could just do:

    SELECT AVG(col1) OVER (PARTITION BY col2) AS partcol1
    FROM tbl
    WHERE partcol1 > 10.0
But I can't, because the WHERE clause is processed before the SELECT clause.

So if I have a bunch of these and want a convenient way to work with the named columns, I have to wrap them into a common table expression:

    WITH cte AS (
        SELECT AVG(col1) OVER (PARTITION BY col2) AS partcol1
        FROM tbl
    )
    SELECT partcol1
    FROM cte
    WHERE partcol1 > 10.0
So wordy.
Post reply on HN