81–90 of 90 posts
Earlier quoted context omitted.
Not everyone has read everything that's ever been posted to HN. There's some utility in reposting, which I think is evident based on how many upvotes this has gotten. I'd never seen this and I'm here almost every day. If you've already seen this, and aren't interested in another look then just move on.
They’re posting related discussions so that interested readers can read further.
Earlier quoted context omitted.
There was a step-change improvement for me when I tried expressing some JS patterns via `underscore.js` instead of procedurally: eg: http://underscorejs.org/#each Thinking of something as `each | map | filter | sum` is waaay less buggy than writing bespoke procedural code to do the same thing. No doubt there is a "cost" to it as well, but the _abstraction_ is valuable. Now, if there were a "compiler" which could opti…
That's kind of what we're aiming for with PRQL (prql-lang.org). While currently it only supports SQL backends, I want to generalize that to things like underscore.js.
For Python, support `prql-to-sqlite3` (in memory?) "out of the box"
For JavaScript, support "array-of-dicts/objects" with no ceremony.
Basically, in python I could justify the depends if I can say:
sql = prql.parse( """select * ...""" )
results = db.execute(sql)
all_my_records = [ { ... }, ... ]
function oh_god_why_nevermind(...) { ... }
subset = prql.execute(
`select * from all_my_records ...`
)
...basically "nobody wants to learn sql nowadays", and in javascript "my kingdom for a left-join!"
Pitch it as "graphql for data" (/zing!)
Earlier quoted context omitted.
That's kind of what we're aiming for with PRQL (prql-lang.org). While currently it only supports SQL backends, I want to generalize that to things like underscore.js.
If I may be so bold as a pitch for adoption: For Python, support `prql-to-sqlite3` (in memory?) "out of the box" For JavaScript, support "array-of-dicts/objects" with no ceremony. Basically, in python I could justify the depends if I can say: sql = prql.parse( """select * ...""" ) results = db.execute(sql) In JS, similarly: all_my_records = [ { ... }, ... ] function oh_god_why_nevermind(...) { ... } subset = prql.exe…
I've recently been updating my stack in other areas and have been utilising "Getting Started" or "Quick Start" sections a lot and thought that we're actually not making that easy enough or easy at all.
I'll look into incorporating your suggestion soon.
If you're up to it, you can open an issue in our repo and then I can ping you when that's done.
KlongPy author here: AMA
https://github.com/briangu/klongpy/blob/main/docs/quick-star... links to an "API Reference" and a "REPL Reference", but the links are broken.
Earlier quoted context omitted.
https://www.timestored.com/b/kdb-qsql-query-vs-sql/ How many database tables have a date time column and a natural ordering? Most the data I look at. Which makes it crazy that sql is based on unordered sets.
Thanks for the link I think this is a really interesting example: > In qSQL this is: aj[`sym`time; t; q], which means perform an asof-join on t, looking up the nearest match from table q based on the sym and time column. > In standard SQL, again you’ll have difficulty: sql nearest date, sql closest date even just the closest lesser date isn’t elegant. One solution would be: > WITH cte AS (SELECT t.sym, t.time, q.bid,…
I'm gonna be the one who asks the dumb question, but someone has to do it: why are expressions evaluated from right to left?
Earlier quoted context omitted.
They’re posting related discussions so that interested readers can read further.
Oh whoops, my bad.
> (Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)
but that's too tedious to do routinely.
Earlier quoted context omitted.
https://www.timestored.com/b/kdb-qsql-query-vs-sql/ How many database tables have a date time column and a natural ordering? Most the data I look at. Which makes it crazy that sql is based on unordered sets.
Thanks for the link I think this is a really interesting example: > In qSQL this is: aj[`sym`time; t; q], which means perform an asof-join on t, looking up the nearest match from table q based on the sym and time column. > In standard SQL, again you’ll have difficulty: sql nearest date, sql closest date even just the closest lesser date isn’t elegant. One solution would be: > WITH cte AS (SELECT t.sym, t.time, q.bid,…
It's just a regular join with the `asof` keyword in front.
The pandas version assumes both fields have the same name, it separates the on and by conditions in a way that's not necessary in SQL version, and imo the "backwards" keyword is a bit ugly and error prone.
I'm gonna be the one who asks the dumb question, but someone has to do it: why are expressions evaluated from right to left?
Think "normal" call syntax like foo(bar(baz(42))) and then remove the superfluous parens foo bar baz 42 The expression is evaluated from right to left. Now, let's make two of the functions into object members: A.foo(bar(B.baz(42))) Remove the parens, extracting the methods from their objects, instead feeding each object as a left argument to its former member function: A foo bar B baz 42 This is normal APL-style call…