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

Re: I don't need your query language

#201

Post by mmh0000 » Sat, Jun 17, 2023, 4:15 PM UTC

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.

I know you specifically mentioned 'vi', but I'm going to blindly assume you meant 'vim'. In which case, as others already pointed out, you can use visual model to get exactly that behavior.

A good mindset to have in regards to Vim is, "Vim can do anything, even make you coffee". The trick with Vim is actually figuring out /how/ to do it.

I highly recommend you start with the VimCasts[1] video series. They're short, 5 minute, videos. With each covering a specific functionality of Vim. They straight to the point, and the author provides samples code for all videos.

[1] http://vimcasts.org/episodes/page/8/

Re: I don't need your query language

#202

Post by croes » Sat, Jun 17, 2023, 4:15 PM UTC

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.

>eliminates all tooling support.

That's an exaggeration. Usually I just start with Select * and build all the necessary joins. For that the tooling support works without problems and when I select the columns in the end it works too.

Re: I don't need your query language

#203

Post by erikpukinskis » Sat, Jun 17, 2023, 4:18 PM UTC

thomasmg wrote: post #197

We write programs with Python, Java, Rust, Javascript and so on. Yet we use a very different language, eg. SQL, to query and modify data. Why? Why don't we use eg. Python as well? SQL is different from other languages: it is declarative, meaning it doesn't dictate how to do it, but what the response should be. Maybe that's the reason? But if that's the case, why are declarative languages not more popular? SQL and oth…

> But if that's the case, why are declarative languages not more popular?

Declarative programming is not very popular because it’s hard to debug. You can’t step through it and inspect intermediate representations. It presents a black box to the developer.

That said, they do seem to show up around certain very complex APIs sometimes.

Besides SQL, CSS is the obvious one.

And I think many parts of otherwise functional/imperative APIs are pseudo-declarative.

For example, React is famously functional in its current form, with render functions and hooks being functions… but then common hooks take a dependency array which is declarative. And at the boundary of these hooks the code is no longer procedural, it disappears into the framework.

> I wish databases have better, faster, and standardized support for a fast procedural language.

That’s a fascinating idea. It would take someone with deep knowledge of a query engine to encapsulate it with a procedural API instead of a declarative one.

That’s not me, but I would love to see it.

Re: I don't need your query language

#204

Post by interleave » Sat, Jun 17, 2023, 4:19 PM UTC

galaxyLogic wrote: post #136

The problem with SQL is that it is not a (very) composable language. The documentation for EdgeDb goes into some detail about that and shows an alternative better language for data-queries. https://www.edgedb.com/showcase/edgeql To understand why SQL is bad, you must first be shown something better, and EdgeDb seems to be such better more composable language.

> The problem with SQL is that it is not a (very) composable language.

I thought the same until a few weeks ago. Then we used the WITH operator for pre-processing and giving things human-readable names.

That helped us manage complexity. The final SELECT statement was very easy to reason about.

Not sure if this is a best (or worst) practice but it helped us ship it.

Re: I don't need your query language

#205

Post by croes » Sat, Jun 17, 2023, 4:21 PM UTC

dan-robertson wrote: post #47

I don’t really find the examples convincing. Like, I get that sql could maybe be written in a slightly less horrid way but I would prefer something a lot less horrid. I think I’m much more motivated by analytics queries than the kinds of thing in this example though. I find sql is poorly suited in this case because it is verbose and written backwards, and often requires many layers of subqueries. That said, one can u…

Why do you need the outermost query?

Re: I don't need your query language

#206

Post by DaiPlusPlus » Sat, Jun 17, 2023, 4:21 PM UTC

christophilus wrote: post #21

tester756 wrote: post #9

Earlier quoted context omitted.

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

What does "proper reflection" mean to you?

Re: I don't need your query language

#207

Post by karmakaze » Sat, Jun 17, 2023, 4:22 PM UTC

> Here is another common argument: SQL was designed with 1970s businessmen in mind, and it shows.

That is a funny way of looking at it. I see that SQL is based on the work of a computer scientist vs DSLs being made by hobbyists, and it shows.

Re: I don't need your query language

#208

Post by croes » Sat, Jun 17, 2023, 4:22 PM UTC

Hendrikto wrote: post #157

Funny how differently things can be framed. You can either call SQL proven and battle-tested, or crusty and outdated, depending on your agenda. Same for the fancy new alternative: It is either fresh and innovative, freed from the shackles of legacy and standard-compliance, or reinventing the wheel in a non-standardized manner.

For data in databases I prefer crusty and outdated

Re: I don't need your query language

#209

Post by DaiPlusPlus » Sat, Jun 17, 2023, 4:24 PM UTC

turboponyy wrote: post #35

tester756 wrote: post #9

Earlier quoted context omitted.

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

The work was already done for them, as LINQ is just do-notation from Haskell.

No, Linq is *not* in any way like Haskell's `do`.

Linq is a (reasonably) compromised, non-referentially-transparent, implementation of a restricted form of relational-algebra with side-effects permitted, so I'm not comfortable describing Linq as "monadic".

Whereas Haskell's `do` is strictly monadic.

Re: I don't need your query language

#210

Post by default-kramer » Sat, Jun 17, 2023, 4:25 PM UTC

nalgeon wrote: post #146

galaxyLogic wrote: post #136

The problem with SQL is that it is not a (very) composable language. The documentation for EdgeDb goes into some detail about that and shows an alternative better language for data-queries. https://www.edgedb.com/showcase/edgeql To understand why SQL is bad, you must first be shown something better, and EdgeDb seems to be such better more composable language.

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 require dynamic SQL (or copy-paste) is considered acceptable.

For the record, I make heavy use of SQL because relational databases are awesome and SQL is the least bad option I've found so far. But the many shortcomings of SQL still annoy me.