We Can Do Better Than SQL • Hacker News Board

Re: We Can Do Better Than SQL

#431

Post by int_19h » Wed, Aug 12, 2020, 3:40 AM UTC

g5becks wrote: post #282

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…

Though I program in languages that most follow the obj.method(args) pattern, I really prefer the args |> function |> function pattern and I wish it was the norm in every programming language.

These are two different use cases. In the first case, which method the call actually dispatches to depends on obj, so it kinda makes sense for it to be syntactically distinct from other args. The pipeline syntax is normally used with free-standing functions that are statically dispatched.

Now, yes, there are languages with multimethods, where the distinction is less obvious. For those that always dispatch on all arguments, a uniform syntax makes more sense. CLOS is a good example.

Re: We Can Do Better Than SQL

#432

Post by int_19h » Wed, Aug 12, 2020, 3:42 AM UTC

gvjddbnvdrbv wrote: post #271

skocznymroczny wrote: post #270

Earlier quoted context omitted.

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.

Dot is not special. Putting the receiver objects first is special, because it allows the IDE to only show verbs (methods) that pertain to that object. If you put the verb first, code completion lacks context, so it would necessarily have to show you all verbs that can apply to any object that could conceivably be acted on in that scope.

Re: We Can Do Better Than SQL

#433

Post by int_19h » Wed, Aug 12, 2020, 3:50 AM UTC

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…

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

It's not that they didn't understand it. There are languages predating SQL that have better syntax.

But SQL was one of the so-called "4th generation programming languages", that were supposed to be operating at a much higher level. And because of that, there was the notion that, if they also have a more "natural" syntax, it would allow people who are not programmers to use them effectively. Hence why SQL was originally SEQUEL - Structured English Query Language. It was meant to be written by domain experts, not database experts.

Of course, that failed (like countless other similar attempts since then), and so now we're stuck with this syntax for no good reason whatsoever.

Re: We Can Do Better Than SQL

#434

Post by int_19h » Wed, Aug 12, 2020, 3:54 AM UTC

jeltz wrote: post #255

smabie wrote: post #140

Earlier quoted context omitted.

Do you love SQL, or do you love relational algebra? Because actual SQL, the language, is pretty shitty. Perhaps the best querying language I've ever used is Q-SQL, integrated into kdb+/q. Unlike SQL, it's actually part of the language (q/k) and, most importantly, it's modular and more expressive than SQL. If you're interested in how we can do a lot better than sending strings to remote databases using an inexpressive…

Not parent poster but I love relational algebra. But so far I have yet to use an alternative to SQL which is less bad. Most of them seem to be designed by people who do not understand SQL.

Take a look at Suneido. As a product, it's a weird thing that kinda stands by itself, and isn't particularly useful because of that. But the database and the query language is straight up relational algebra.

https://suneido.com/info/suneidoc/Database/Queries/Syntax.ht...

Re: We Can Do Better Than SQL

#435

Post by lmm » Wed, Aug 12, 2020, 5:19 AM UTC

marcosdumay wrote: post #346

lmm wrote: post #239

Earlier quoted context omitted.

And with good practices (mainly a decent type system that lets you distinguish between checked and unchecked values) you'll have no problems with constraints in the application layer either.

As long as your application layer is a single homogeneous application running the same code. That is approximately never the case. Current widespread practices are moving away from it, with multi-services, and old fashioned practices of mixing customized and off the shelf tools basically forbid it.

Current practice is moving away from the idea of having your storage layer be a single homogeneous datastore as well.

Re: We Can Do Better Than SQL

#436

Post by soobrosa » Wed, Aug 12, 2020, 5:24 AM UTC

Still https://erikbern.com/2018/08/30/i-dont-want-to-learn-your-ga...

Re: We Can Do Better Than SQL

#437

Post by trapatsas » Wed, Aug 12, 2020, 5:51 AM UTC

No, you can’t. Another competing standard against SQL will die trying to be SQL.

Re: We Can Do Better Than SQL

#438

Post by okaleniuk » Wed, Aug 12, 2020, 6:42 AM UTC

throwaway_pdp09 wrote: post #108

okaleniuk wrote: post #104

Ergonomics of a language I don't know is always worse than that of I do know. As long as there's nothing valuable in the technology itself why would I bother changing things?

> As long as there's nothing valuable in the technology itself You're assuming there's nothing valuable. I'd say there is. Whether that's enough to displace SQL I really doubt.

Maybe there is. I didn't try it. But it's written rather explicitly "OK, so we have highlighted the shortcomings of SQL. Why do they matter? It’s all about ergonomics." That's what drove me off.

Re: We Can Do Better Than SQL

#439

Post by kabacha » Wed, Aug 12, 2020, 7:25 AM UTC

I'm a senior dev that up until recently managed to avoid having SQL in my knowledge stack as we've always used no-sql databases.

I knew the basics but I took a weekend to catch up on some more advance use cases and I can really resonate with this article. Unsurprisingly I came down to a conclusion that SQL is just a bad language, no matter how you look at it. It throws away every code flow standard in favor of their own nonsensical flavor. Where normal synchronous programs go top-to-bottom SQL is a complete spaghetti of flow and logic.

Just take a look at the most basic syntax: `SELECT person.name FROM person` The variable is defined at the end of the program which is just absolutely silly, what if the program is 100 lines long; do I need to start reading from the bottom? SQL must be the reason mouse scroll wheels were invented.

As an alternative take a look at view based systems: `for person in people: yield person.name` — isn't it infinitely more understandable and readable?

Unfortunately it seems SQL is here to stay as most people would rather work with this mess rather than invest some time to adopt something better.

Re: We Can Do Better Than SQL

#440

Post by lowwave » Wed, Aug 12, 2020, 7:45 AM UTC

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…

It is very common to hear from new developers who are not familar with declaritve programming to complain about SQL. They don't tend to see the SQL syntqax fit into their 'programming' paradim. It is very simple, SQL is magic box, you ask it what you want, and it gave it to you. It is around for so long for a reason.