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

I don't need your query language

antonz.org

Post reply on HN
Print view View original

21–30 of 304 posts

Re: I don't need your query language

#21

Post by christophilus »

tester756 wrote: post #9
LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

C#'s LINQ (query syntax, not methods) got it right var result = from s in stringList where s.Contains("Tutorials") select s;

LINQ and proper reflection are what I miss most from C#. (I’m all Typescript at the moment.)

Re: I don't need your query language

#22

Post by ellisv »

XorNot wrote: post #5
LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

FROM users SELECT name, id, location WHERE name LIKE 'a%'; You know I think you're right.

Eh. I’m not convinced by this. I may know what I want to query as often or more than knowing where it comes from.

I suppose it could be nice if the user could specify clauses in an arbitrary order but it’d certainly add complexity.

I don’t find it difficult to jump around a bit from clause to clause while writing a query. In fact, it’s incredibly rare to write a query straight through and have it do what you want it to do.

Re: I don't need your query language

#23

Post by xyzzy_plugh »

danielheath wrote: post #19
LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

This is also my primary issue with vi. d3w (`d`elete `3 w`ords) cannot be highlighted / indicated in any way ahead of time. If the motion specifier came first, it could be.

v3wd?

Re: I don't need your query language

#24

Post by n_e »

LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

In most tooling, you can write SELECT FROM table, then go back to the select list and have autocomplete work.

The situation could certainly be better, but at least this works today.

Re: I don't need your query language

#25

Post by ellisv »

badestrand wrote: post #13
kristiandupont wrote: post #8

Earlier quoted context omitted.

GP clearly shows why it is. I think SQL is great but their point is spot on.

The wrong order in the statements is a minor inconvenience but the widespread use and having an industry standard is 100x as valuable.

Agreed. The last thing I need is more flexibility in how people write queries. It would be shortly followed by numerous aggressive query formatting tools. Things would get messy fast.

Re: I don't need your query language

#26

Post by 6510 »

XorNot wrote: post #5
LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

FROM users SELECT name, id, location WHERE name LIKE 'a%'; You know I think you're right.

O well, if we are going to be like that?:

FROM users WHERE name LIKE 'a%' SELECT name, id, location

(I should refresh the page before posting)

Re: I don't need your query language

#27

Post by frognumber »

I'm working on a query language right now!

Why not SQL?

Lack of tooling for SQL.

Yes, SQL lacks tooling. There's a ton of stuff to build a SQL client, obviously. However, on the other side:

- I have no sane way to parse SQL

- I have no sane way to comprehend SQL

Writing a SQL query system would be many months of work. Tossing together a good-enough query language with standards like JSON or YAML means I can json.loads(query) in Python and JSON.parse in JavaScript.

SQL would be an ideal fit if there was good tooling, and it fits in more places than most people realize. Web API query a whole bunch of stuff stored in all sorts of complex ways. SQL is better on paper than RESTful / AJAXy / GraphQL / etc. APIs.

It's not better if it means that the query language takes more time to build out than the entire rest of the system.

TL;DR: If you want to build a high-visibility open-source project and guarantee employment for the rest of your life, an elegant SQL parser, especially for building web APIs, would be a great thing to do.

Re: I don't need your query language

#28

Post by smitty1e »

LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

The query is just a requirements statement.

After parsing and analysis steps, the system is going to do what it does with the statement, no?

The syntax is for the user, not the system.

Re: I don't need your query language

#29

Post by RyanHamilton »

Show me an elegant SQL version for the queries in this article: https://www.timestored.com/b/kdb-qsql-query-vs-sql/ Particularly when you are trying to run queries where order matters, e.g. top 3 posters by topic on HN. You will find it much more annoying. Fundamentally SQL is based on the concept of tuples/sets which have no order so there's no way to avoid it being messy. What you want is a database based on the concept of an ordered list, suddenly what is complex in standard set SQL becomes easy in almost any other language. My second big complaint would be that SQL isn't really a programming language. Parts have been bolted on by various vendors or they now let you run python/java on the SQL server but considering how heavy SQL already is, having a full blown language may actually be less cognitive load than learning all the sub variations of language implementations.

Re: I don't need your query language

#30

Post by interleave »

I had a similar experience this month. We've been pair-programming using Dbt to write "long-form" SQL to bubble up a report to our business users.

After an initial "Uh-oh, I haven't manually written complex SQL in a while..." it all came back fast enough (Thanks, first-semester relational algebra!). Turns out, sql is well-suited for business "in-queries"!

The things that made us scratch our heads came from how the schema had evolved over time. We now have those hairballs at least 'contained' and visible. And it's all pretty readable imho.

I guess my initial unease came from using ORMs for CRUD persistence and very rare exploration. And holy moly, I'm grateful for ORMs. I wouldn't want to manually write those inserts and updates.

So, I guess it depends on what you want to accomplish with your database.

Btw: A HUGE shout-out to Dbt and Dbt cloud for letting us treat sql as code. Didn't expect to love it that much. How was this not a thing earlier?

Post reply on HN