Live data from Hacker News

I don't need your query language

antonz.org

291–300 of 304 posts

Re: I don't need your query language

#291
post #191

Earlier quoted context omitted.

> So 3w could select three words but also move the cursor to the end of selection I mean, if you hit v first, that's exactly what it does.

Yes, but in terms of editing speed and comfort, one keystroke is the difference between life and death. As long as the motion can be described in a single command, visual mode is overkill.

Wouldn't what you're proposing complicate the rest of normal mode though?

Or is this just reversing the order so it's {motion}{verb} instead of {verb}{motion}?

Re: I don't need your query language

#292
post #7

Earlier quoted context omitted.

Ain't broke.

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

That's just his opinion. SQL does it's job extremely well, is relatively easy to parse for its inherent complexity. That somebody would like FROM before SELECT or WHERE after GROUP BY is of no consequence.

Re: I don't need your query language

#293
post #66

Earlier quoted context omitted.

I get around this when hand coding by doing a quick 'SELECT * FROM', adding my joins, then going back and filling in the fields using intellisense. Intellisense doesn't know what columns are available until the FROM clause is handled. To me, this is a slight annoyance with an easy workaround. If the SQL spec gets updated to allow switching the clauses around, I'll be pleased. But I'm not about to change languages ove…

Oh, that's a great idea. What editor/ui do you use? Since I've got divorced from Jetbrains I miss Datagrip ...

Why the divorce? DataGrip has been the best database-gui that I've ever used.

Re: I don't need your query language

#295
post #66

Earlier quoted context omitted.

I get around this when hand coding by doing a quick 'SELECT * FROM', adding my joins, then going back and filling in the fields using intellisense. Intellisense doesn't know what columns are available until the FROM clause is handled. To me, this is a slight annoyance with an easy workaround. If the SQL spec gets updated to allow switching the clauses around, I'll be pleased. But I'm not about to change languages ove…

Oh, that's a great idea. What editor/ui do you use? Since I've got divorced from Jetbrains I miss Datagrip ...

vscode. mssql plugin because that's what I'm dealing with.

Re: I don't need your query language

#296

Earlier quoted context omitted.

I tell new developers that SQL is one of those few things in our field you get to keep forever. That JavaScript framework that takes a year to understand will no longer be used in 7 years. SQL is going to be here forever and learning it is useful your whole career. Other common entries on this list of forever tools: regular expressions, emacs, bash/shell scripting, excel, probably more I’m forgetting. Devs always pus…

The problem is that a lot of developers consider things forever tools when they are not forever tools and not even close. SQL is one of the forever tools, but even in your short list I would absolutely strike down two of them as "forever tools". They're more like "my favorites that I've invested decades into".

Forever is a stretch, maybe “until the end of my career” tools. That list of tools could eventually be replaced, but I bet whatever comes after them will be forced to adopt a lot of their metaphors to gain acceptance. For instance, maybe excel eventually gets replaced, but the thing that kills it will feel a lot like it. The experience won’t be wasted, useful things you learned to do in it will continue to be useful in the new tool.

Re: I don't need your query language

#298
post #288
post #253

I feel like this entire debate is strongly influenced, if not soon made obsolete and pointless, by the presence of the so called AI tools. Feels like there's a universe of difference between the experience of "carefully craft the query yourself" and "describe the query and let AI write the code for it."

oh let's just see that world where "AI" is "writing" the SQL queries and see how that goes. LLMs work by hallucinating mashups of existing code examples stolen from webpages. Writing correct SQL for complex cases definitely needs real understanding, not just elaborate typeahead.

Oh, I agree, I meant to add something like "after the fact, a human needs to inspect." But it still feels like this would speed up time dramatically.

Re: I don't need your query language

#299

Earlier quoted context omitted.

Oh, that's a great idea. What editor/ui do you use? Since I've got divorced from Jetbrains I miss Datagrip ...

Why the divorce? DataGrip has been the best database-gui that I've ever used.

I had the all-tools subscription for years (working mainly on Spring Boot and Angular projects) and IntelliJ and Webstorm were fantastic. Then I started Vue projects and later on Svelte and the Webstorm support for both (and Tailwind btw.) has been a disaster. Esp. how they handled the countless issues created by me and many others. Many other small annoyances like no support for international keyboards with dead keys on Linux and esp. how support handled it.

So, I had to move to VS Code for Vue and Svelte and as I didn't want to use 2 different IDEs I canceled my JB subscription. So far VS Code is pretty good for Goland and Rust as well, but as you said, I struggle to find something as good as DataGrip for SQL. Maybe I should just get a DataGrip license (single tool).

Edit: I forgot another issue ... DataGrip didn't support the latest SQLite version for a very long time, as the maintainer for the open source Java client wasn't working on it. When I dared to ask the JB support a second time for the status after a while, I got a stroppy reply from the responsible Jetbrains engineer, as how I dare asking twice and there's nothing Jebrains could do when the single person maintainer of an open source lib is doing other stuff with his life. Crazy.

Re: I don't need your query language

#300
post #271

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.load…

Could you tell me what you want to accomplish by reimplementing query system? I really curious, because generally query systems used to query data from DB..

I'm working on a platform where data changes in real-time, often every few milliseconds. It's not stored in a DB, and a lot of it is computed on-the-fly.

What I want to query is a perfect fit for SQL. However, it's very much not in a database.

I also don't need a subset of SQL. I would need things like stored procedures and ideally things like virtual tables. There's a lot of computation going on in the queries. The postgres can represent 100% of what I want, but it's a big complex syntax.

In an ideal case, I could pick up pieces and run with them. I think I could reuse parts of things like a query optimizer too.

Post reply on HN