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

141–150 of 304 posts

Re: I don't need your query language

#141

Post by DaiPlusPlus »

recursive wrote: post #133
DaiPlusPlus wrote: post #20

Earlier quoted context omitted.

or just `var result = stringList.Where( s => s.Contains("Tutorials") )` I can't stand the non-extension-method Linq syntax: the _only_ place where it offers a readability improvement over ext-methods is using `join` - but I hardly ever do that in Linq anyway. Also, in both my code and yours, `result` will be a lazy-evaluated `IEnumerable ` which may be undesirable - which means it's probably a good idea to use `.ToLi…

> the _only_ place where it offers a readability improvement over ext-methods is using `join` No love for let? from item in items let frob = Expenseive(item.P1) where frob > 3 selec new { frob, item }

That can be done with ValueTuples instead of Anonymous Types: `items.Select( i => ( i, frob: Expensive( i.P1 ) ) ).Where( t => t.frob > 3 );`

...and ValueTuples are superior to Anonymous Types because you can actually return them from a function or use them as parameters - whereas Anonymous Types cannot cross method-call boundaries (excepting using generics for pass-through).

Anonymous Types in C# were a massive mistake. They should be [Obsolete]'d, IMO.

Re: I don't need your query language

#142

Post by tomnipotent »

mattmanser wrote: post #131
tomnipotent wrote: post #111

Earlier quoted context omitted.

> you can't use 'negigibly' worse as a defence Absolutely you can when the increase in something (bandwidth) in a system with surplus supply with the trade-off of optimizing a more constrained supply (CPU or memory). > made a crazy SQL select instead of a normal one, which is harder to maintain. Purely subjective. Myself nor the people I've hired would have a problem maintaining a more complex SQL query using CTE's a…

It's not subjective, it's.objective. This solution for tuples is objectively worse in every way, throughout, network bandwidth, code complexity, maintainability, error likeliness. You're just clearly someone who can't admit when they're wrong.

> it's.objective.

Prove it.

> You're just clearly someone who can't admit when they're wrong

You don't have a good technical argument so you jump to ad-hominem's?

Re: I don't need your query language

#143

Post by DaiPlusPlus »

recursive wrote: post #138
rjbwork wrote: post #106

Earlier quoted context omitted.

>I can't stand the non-extension-method Linq syntax: the _only_ place where it offers a readability improvement over ext-methods is using `join` Hah! I tell the juniors this all the time :D. This seems to be basically the consensus among the C# community these days as far as I can tell as well.

I guess I'm not in the C# community. `let` is pretty annoying to reproduce with extension methods. Also, when you use multiple `from` clauses, you get access to all scopes, whereas with `SelectMany` you only get the parameters of your current lambda.

> you get access to all scopes

Read: "you create new heap-allocated closures which wreck your Linq expression's runtime performance"

Or:

"you create Linq queries that cannot be translated into SQL"

Re: I don't need your query language

#144

Post by DaiPlusPlus »

gemstones wrote: post #124
eastbound wrote: post #80

Earlier quoted context omitted.

I’ve had a first-of-class linuxian excellent developer but junior, tell me that we need Kafka because our SQL requests took 3 seconds. It should be a single INSERT, but through an ORM that multiplies it. The only upside of Kafka is not having the ORM…

In this case, you are the senior that needs to bypass the ORM and just use whatever raw parameterized query support exists in your ORM of choice.

> whatever raw parameterized query support exists in your ORM of choice

That doesn't help with conditional-predicates - that's another major shortcoming in SQL.

Re: I don't need your query language

#145

Post by benrutter »

Maybe I didn't grok this article but all the examples made me think "fancyql" (as it calls it) looks a lot better than SQL.

If I could compile back and forth between SQL and "fancyql" then using fancyql feels like an absolute no brainer to me?

I'm a lot less sympathetic to the "everyone already knows it" argument after dealing with SQL queries that are many hundred lines long.

Re: I don't need your query language

#146

Post by nalgeon »

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

Re: I don't need your query language

#147

Post by littlestymaar »

tomnipotent wrote: post #95
mattmanser wrote: post #93

Earlier quoted context omitted.

I think you're wrong, happy to be corrected though. As far as I can tell, if you change a subselect column into JSON, it's much more expensive in CPU and marginally more expensive in network bandwidth. 1. The data has to be serialised into JSON on the DB server, which costs CPU. 2. It then has to be deserialised on the application server (unless your backend is written in javascript and then your throughput problem i…

> which costs CPU Which costs very little CPU in 2023. > deserialised on the application server This is true regardless. The low-level libraries are still parsing the stream into meaningful in-memory structures. With JSON, the low-level library only has to parse a variable length string, then JSON decode. I'm unfamiliar with any language in 2023 that doesn't have incredibly fast and efficient JSON parsers. > bandwidt…

> Which costs very little CPU in 2023.

That's a very bad argument for an RDBMS, since you want to make it scale vertically as much as you can (unlike your application server, horizontally scaling your database is a completely different matter, and isn't straightforward at all).

Re: I don't need your query language

#148

Post by madsbuch »

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 definitely something that makes tooling harder. But I think it is because tooling is though up wrongly.

Consider `SELECT 0 AS some_num`. This does not have a FROM clause.

While this example seems contrived, there are several examples of queries where the FROM clause is not just a listing of tables. Especially when moving into larger projects in SQL.

Re: I don't need your query language

#149

Post by grose »

SeanLuke wrote: post #127

What happened to Datalog?

I was hoping for a Datalog shoutout.

I like SQL, but it has a few disadvantages compared to Datalog.

- In Datalog, queries and the data itself are homoiconic; the structure for both is exactly the same. Uses first-class variables to represent unknowns.

- Easy to compose queries (just tack on another predicate)

Of course it has the disadvantages that it's not widely supported (outside of Datomic/Clojure/Prolog ecosystem?), and not as popular, and maybe even more difficult to optimize [citation needed].

I would love to see a new Datalog-based DB. SQL-but-slightly-different-syntax is "lipstick on a pig" as they say, not very compelling IMO (and not really novel either, you can see it reinvented in every ORM).

Re: I don't need your query language

#150

Post by Psyladine »

gozzoo wrote: post #37
DaiPlusPlus wrote: post #18

SQL does have a significant drawback w.r.t. how databases are used today (imo): a SELECT query can only return a single resultset of uniform tuples: if you want to query a database for hetereogenous types with differing multiplicity (i.e. an object-graph) then you either have to use multiple SELECT queries for each object-class - or use JOINs which will result in the Cartesian Explosion problem[1] which also results…

Isn't your comment judging a fish by its ability to climb a tree?

You're asking those whose object problem model is a FOR loop not finding set based operations intuitive, efficient or ever necessary?
Post reply on HN