I don't need your query language • Hacker News Board

Re: I don't need your query language

#241

Post by lostdog » Sat, Jun 17, 2023, 6:14 PM UTC

kubanczyk wrote: post #225

idoubtit wrote: post #88

Earlier quoted context omitted.

> Usually start with "select * from table limit 10", look at the columns and data available, and then start refining. An experienced person won't do that. For any moderately complex SQL query, before writing it I already have in mind the several jointures I'll need, since I usually know the tables and FK I'm working with. It's like following the edges of a graph, all in my head. But I don't know all the fields of the…

> have in mind the several jointures I typically keep all JOINs I've ever used on that schema in a single file, one per line. Before writing a new query I can just copy paste some JOINs, simply skimming through table names like lego bricks. That way it's surprisingly easy to beam from domain problem to a new query that uses 10 or 20 tables. I've just realized that it might be all archaic now, in LLM era.

This is a great idea in practice, but it really points to how sql could improve.

You have a library of useful joins that you've checked for correctness. Saving the library as reusable code would be even more useful.

Re: I don't need your query language

#242

Post by alexchamberlain » Sat, Jun 17, 2023, 6:18 PM UTC

waboremo wrote: post #226

nickpeterson wrote: post #72

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".

Which 2 would you strike down out of interest?

I wholeheartedly agree that engineers massively underestimate the power of Excel.

Re: I don't need your query language

#243

Post by revskill » Sat, Jun 17, 2023, 6:18 PM UTC

How about nested selection ? SQL is dump because it doesn't allow nested selection by default.

Re: I don't need your query language

#244

Post by camgunz » Sat, Jun 17, 2023, 6:22 PM UTC

default-kramer wrote: post #210

nalgeon wrote: post #146

Earlier quoted context omitted.

SQL is infinitely composable. Each SELECT returns a relation that another SELECT can query (or combine with another relation using set operators like UNION etc).

I suppose it's infinitely composable in that very limited dimension, but SQL's critics are asking for composability in other dimensions. For example, say I have a pretty long query of some Order table. Now I want the exact same query, but it should start from the OrderArchive table instead. How do you do this? Dynamic SQL? The world has lambasted Javascript for much less, but somehow the fact that so many tasks requi…

The answers are stored procedures and templates. People argue against them, but they're basically the data versions of software affordances we already have.

Re: I don't need your query language

#245

Post by tikhonj » Sat, Jun 17, 2023, 6:28 PM UTC

9dev wrote: post #239

tikhonj wrote: post #238

Having used (a lot) of Hive SQL, I absolutely do need your query language. SQL is fundamentally incapable of expressing any sort of abstraction, so non-trivial queries quickly become completely incomprehensible, unmaintainable and bug-prone. Learning a new language is a one-time, up-front cost. Dealing with an awkward, inexpressive query language that integrates poorly with my main language, my types or my interface…

Not that I fundamentally disagree with you, but SQL has been the dominant query language for more than half a century. This lends it some credence for being a quite passable solution, don’t you think?

It's evidence that SQL isn't entirely unusable—but I've worked with too much popular technology to believe it means anything more than that.

Re: I don't need your query language

#246

Post by psnehanshu » Sat, Jun 17, 2023, 6:28 PM UTC

smitty1e wrote: post #28

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.

Sure, but the parent is speaking about how it is difficult for tooling to present with options when it doesn't know which table to select from.

Re: I don't need your query language

#247

Post by recursive » Sat, Jun 17, 2023, 6:30 PM UTC

DaiPlusPlus wrote: post #230

recursive wrote: post #212

Earlier quoted context omitted.

It was all in memory. To the extent that it's a performance tradeoff, it might be one that's worth making depending on the use.

Aye - but the annoying thing is that it was never necessary: with a few subtle changes to Linq it’s possible to have allocation-free closures by passing state via hidden parameters on the stack - but just like every language out there we’re now hobbled by decisions made 15 years in the past. —— On a related note, it’s interesting just how unpopular so many new C# language features are (just by looking at the numbers…

Interesting.

I think there are some otherwise-seldom-used linq overloads for doing just that. Maybe on Join() or GroupJoin() or something like that. Query expressions use them for compilation to keep closure use down, but I don't know too much about it.

Anyway, if top-level statements are wrong, I don't ever want to be right. I had no idea there was any controversy on that. It's trivial to add the boiler-plate back in if you want it.

The main thing that bugs me is that Expression is stuck with language features that existed in C#4, even when there are trivial lowerings. e.g. `is not null` could be `!= null`. (This example ignores operator implementations, but most IQueryables ignore more than that already) Even better, add AST node types for the new language features.

Re: I don't need your query language

#248

Post by Luctct » Sat, Jun 17, 2023, 6:34 PM UTC

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;

Tcl dicts do something very similar, and Tcl is very well integrated with SQLite.

Re: I don't need your query language

#249

Post by kagevf » Sat, Jun 17, 2023, 6:55 PM UTC

I was exposed to Kusto Query Language this week. I used it to query logs in Azure. At first, I thought "what? Another query language to learn? " But I find myself liking it. It reminds me of ML style piping expressions, and it's very explicitly lays out how each operator works on top of previous clauses, which makes it very clear how and when each clause works. I'm assuming / hoping the queries that are actually executed are deferred - I would think they would have to be!

Re: I don't need your query language

#250

Post by PhilipRoman » Sat, Jun 17, 2023, 7:14 PM UTC

Kamq wrote: post #191

PhilipRoman wrote: post #71

Earlier quoted context omitted.

I think these two concepts could be reconciled by having selection be combined with moving. So 3w could select three words but also move the cursor to the end of selection, ready to process another normal mode command. The highlighting would need to be scaled back a little (perhaps a dark gray background), as you don't want your entire screen to light up when moving but I think it's doable.

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