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

271–280 of 466 posts

Re: We Can Do Better Than SQL

#271

Post by gvjddbnvdrbv »

skocznymroczny wrote: post #270
kd5bjo wrote: post #230

Earlier quoted context omitted.

> 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 thi…

It's not that simple, D has UFCS (Uniform Function Call Syntax), which makes object.method(args) and method(object, args) equivalent calls. Also there's a non-language related advantage of dot notation. Type the name of the object, press dot and IDE will show you what things you can do with that object. You don't have that with other notations.

Why is dot special? Fortran uses % (if I remember properly) IDE's can complete after a % as well as after a dot.

Re: We Can Do Better Than SQL

#272

Post by CodesInChaos »

enjo wrote: post #89
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…

XKCD’s comic on competing standards feels appropriate here: https://xkcd.com/927/

I don't think treating query languages as a standard is the right comparison here. I think it's great that programming languages have evolved from C or PHP quality languages. I view SQL like PHP, I can write it if I have to, but it's certainly not a language I enjoy working with. EdgeQL has its flaws, but it still looks like a big improvement over SQL to me.

Re: We Can Do Better Than SQL

#273

Post by Akronymus »

scotty79 wrote: post #268
Akronymus wrote: post #146

Earlier quoted context omitted.

I love SQL for making it possible to almost trivially enforce most business rules. Such as: You can only use one of the in another table specified values in this field.

It makes some things simple and insanely fast at runtime, at the cost of making other things impossible or if possible horribly awkward and just as slow as in any other programming language.

In those rare cases, you can do post processing on the data in code if need be. I personally don't see it fully as either/or but as mostly SQL with enhancing the data in rare cases via "traditional" code.

Re: We Can Do Better Than SQL

#274

Post by thanpolas »

ckocagil wrote: post #32

I'm not impressed for two reasons: 1. Anyone striving to build a better SQL should make a comprehensive list of common (but difficult!) database tasks for OLTP and OLAP workloads. This will expose the weakness of their language. SQL has had 50 years and myriads of improvements to cover all these common cases. This is not a fair fight, so come prepared. 2. It's not enough to be just "better than SQL" to replace it. SQ…

3. The evolution of SQL should be an open standard, backed by academics and the community. Not a proprietary solution proposed by a company.

Re: We Can Do Better Than SQL

#275

Post by thanpolas »

roudaki wrote: post #261

Stupid question, slightly off-topic but why every web app needs to be ready to scale and serve a billion users? I don't mean this in the pessimistic way of "be real you are not next Facebook". My question is what do you think all that money is for, one you are asking for from VCs? Facebook was not ready for a million users in the beginning. You need old stable and safe tech that will not crash your demo or provide ho…

It doesn't. Who claimed that?

Re: We Can Do Better Than SQL

#276

Post by jasonpbecker »

skocznymroczny wrote: post #270
kd5bjo wrote: post #230

Earlier quoted context omitted.

> 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 thi…

It's not that simple, D has UFCS (Uniform Function Call Syntax), which makes object.method(args) and method(object, args) equivalent calls. Also there's a non-language related advantage of dot notation. Type the name of the object, press dot and IDE will show you what things you can do with that object. You don't have that with other notations.

That assumes a very OO mindset. method(object, args)/function(data, parameters) works better in other languages, and IDEs can handle this quite well without dot syntax.

Which goes to your point-- form follows function, in syntax as with many other things.

Re: We Can Do Better Than SQL

#277

Post by thom »

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…

Except that dplyr is horribly slow and memory inefficient, and (if you were minded to actually put R code into production) it more or less forces you to do data prep in a database anyway.

Re: We Can Do Better Than SQL

#279

Post by dilandau »

>sql alternative #1427904 that absolutely nobody will ever use

Love it or hate it, sql is a standard and there is a ton of knowledge (stackoverflow answers, books, tutorials) and tooling (query builders, orms). This is either hopelessly naive, or hopelessly arrogant.

Post reply on HN