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

We Can Do Better Than SQL

edgedb.com

Post reply on HN
Print view View original

221–230 of 466 posts

Re: We Can Do Better Than SQL

#221

Post by m000 »

Areading314 wrote: post #141
tqi wrote: post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

Right, it's like criticizing python, or English, for being inconsistent, or "large". Turns out that doesn't matter -- what matters is that the language is useful because it has a wide base of users and libraries, just like SQL does.

Python and English are meant to be general purpose languages, so they are kind of expected to be large and occasionally inconsistent. SQL is (by definition) a domain-specific language which has grown out of proportions.

Are there really any SQL libraries in the traditional sense (i.e. reusable/composable SQL code with a well specified API)? SQL "libraries" typically focus on hiding the inconsistencies and the abhorrent syntax under the carpet.

And the user base is there, mostly because of the database engine properties and features. The query language itself is just a bad side-effect. And TFA does make a point that NoSQL abandoning the underlying RDBMS model is in fact a regression.

Re: We Can Do Better Than SQL

#222

Post by krick »

roenxi wrote: post #181
tqi wrote: post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

> SQL is messy because describing the underlying data relationships are messy. > SELECT extract(day from timestamp '2001-02-16 20:38:40'); SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is. The 'from' in that extract does nothing and I can't easily identify if extract is a function or some sort of crazy parsing construct - what are the arguments…

> all the syntax decided on before there was a community that really understood what good syntax is

Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn't really that important". Most modern languages loosely follow either something C-like or Algol-like, most people like what they are familiar with. There are sometimes claims that a good syntax should be successfully parsed by some relatively simple parser (which is totally not obvious, TBH, because while it is clear why C++ is a good counter-example, we don't really have that many good examples: classic LR-parsers or something like that are really not that powerful, and most real-world programming languages implement something very non-generic of their own). Some people claim that "good syntax is no syntax" (Lisp), and some say that Haskell has a good syntax (ikr). The bottom line being that this is just a matter of taste, unlike most of what we can say about types and data structures.

So, to summarize: I never actually heard a compelling general theory of good syntax.

This is completely offtopic, BTW, I agree that SQL is trash and it is even kinda funny that somebody tries to defend it like that, since for a long time it was sort of a textbook example of "why a language created with the idea to be used by non-technical people is a failure from the very beginning".

Re: We Can Do Better Than SQL

#223

Post by klmr »

roenxi wrote: post #181
tqi wrote: post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

> SQL is messy because describing the underlying data relationships are messy. > SELECT extract(day from timestamp '2001-02-16 20:38:40'); SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is. The 'from' in that extract does nothing and I can't easily identify if extract is a function or some sort of crazy parsing construct - what are the arguments…

As a point of minor historic curiosity, the pipe operator in R actually predates dplyr and was invented independently multiple times by various people who noticed that the Unix model translates well to data transformations in R (F# also has a pipe but I'm not aware of anybody using F# as an inspiration for the pipe in R).

Re: We Can Do Better Than SQL

#224

Post by [deleted] »

m000 wrote: post #221
Areading314 wrote: post #141

Earlier quoted context omitted.

Right, it's like criticizing python, or English, for being inconsistent, or "large". Turns out that doesn't matter -- what matters is that the language is useful because it has a wide base of users and libraries, just like SQL does.

Python and English are meant to be general purpose languages, so they are kind of expected to be large and occasionally inconsistent. SQL is (by definition) a domain-specific language which has grown out of proportions. Are there really any SQL libraries in the traditional sense (i.e. reusable/composable SQL code with a well specified API)? SQL "libraries" typically focus on hiding the inconsistencies and the abhorre…

[deleted]

Re: We Can Do Better Than SQL

#225

Post by nl »

Zamicol wrote: post #196
mathgladiator wrote: post #96

Earlier quoted context omitted.

No, I'm with you and prefer SQL for many tasks. SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale". SQL as a language within other languages is a nightmare from a security standpoint, and if language integrated query was more common across languages earlier on then this wouldn't have been an issue. Databases generally depend on normalization, but normalization comes with inte…

What is a good "web scale" solution?

These days, SQL.

It's true that in the 2000-2010 period many SQL implementations struggled to scale with growth in websites (many other parts of the webstack did too).

Re: We Can Do Better Than SQL

#226

Post by rjmunro »

grandinj wrote: post #191

SQL was designed by COBOL / NATURAL people and was intended to be used by "normal people". That was part of a larger movement at the time to make programming more accessible. Unfortunately (a) that experiment mostly failed (b) the resulting syntax does not compose well at all (c) the syntax does not represent the underlying semantics and mathematical operations well at all. The combined effect is a rather tortured la…

What is needed is a way to use something like the new language presented here against existing relational databases, preferably in a way that doesn't involve sending queries as plain text strings back to the database engine - query compilation should happen in the client library, and be sent to the database as some sort of bytecode.

Support for this bytecode should be added to Postgres, MySQL etc, not some new database product. Projects should be able to mix old style SQL queries and queries written in the new language at will.

Re: We Can Do Better Than SQL

#227

Post by josefrichter »

tqi wrote: post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

the first paragraph of your response was unnecessary, or perhaps could have been worded more constructively

Re: We Can Do Better Than SQL

#228

Post by jacquesm »

grandinj wrote: post #191

SQL was designed by COBOL / NATURAL people and was intended to be used by "normal people". That was part of a larger movement at the time to make programming more accessible. Unfortunately (a) that experiment mostly failed (b) the resulting syntax does not compose well at all (c) the syntax does not represent the underlying semantics and mathematical operations well at all. The combined effect is a rather tortured la…

> SQL was designed by COBOL / NATURAL people and was intended to be used by "normal people".

That's not how I remember it. What I recall is that SEQUEL was the result of looking at how databases and set theory could be connected.

https://en.wikipedia.org/wiki/Edgar_F._Codd

That had nothing whatsoever to do with COBOL or NATURAL.

Re: We Can Do Better Than SQL

#229

Post by pkalinowski »

nicoburns wrote: post #218
quickthrower2 wrote: post #122

Earlier quoted context omitted.

I love SQL. I'd love someone to make it better for complex queries. Have you seen the enterprise SQL monstrosities. Why do we have ORMs if SQL is perfect?

Completely agree. For example, why isn't there functionality to define aliases for complex expressions and then reuse those through a query. Simple query-local SQL functions would be nice too. I'd love to see a "SQL-like" language that compiles down to SQL itself, much like Babel or TypeScript in the JavaScript world. I think the tricky thing is that there is no single SQL target.

> Completely agree. For example, why isn't there functionality to define aliases for complex expressions and then reuse those through a query. Simple query-local SQL functions would be nice too.

What about common table expressions? Or custom defined functions?

    with X as ( select... )
It's widely used for analysis

Re: We Can Do Better Than SQL

#230

Post by kd5bjo »

krick wrote: post #222
roenxi wrote: post #181

Earlier quoted context omitted.

> SQL is messy because describing the underlying data relationships are messy. > SELECT extract(day from timestamp '2001-02-16 20:38:40'); SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is. The 'from' in that extract does nothing and I can't easily identify if extract is a function or some sort of crazy parsing construct - what are the arguments…

> all the syntax decided on before there was a community that really understood what good syntax is Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn…

> So, to summarize: I never actually heard a compelling general theory of good syntax.

I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of this.

My pet theory about why the object.method(args) call syntax won is that it really is the most natural to read, as evidenced by the fact that most human languages follow subject-verb-object word order.

Post reply on HN