5 ms·

I already have a JSON query language - it’s JavaScript. > Queries are 80% shorter than imperative code From the examples they look the same length as the corr

I already have a JSON query language - it’s JavaScript. > Queries are 80% shorter than imperative code From the examples they look the same length as the corresponding JS I would write, maybe slightly longer. What are the advantages to using this language over JS? JS has a fast JIT which would make filtering data fast. How does this query language compare in performance? Does it have indexes?

markstos 5y ago
Good points. JSON processing tools I find helpful in addition to JavaScript include Gron aka "grep for JavaScript" ( https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron ), jq for querying, json_pp for pretty-printing and `bat` for syntax highlighting.
Mariehane 5y ago
This does some clever stuff in the background, e.g. query optimization and performing the computations of a 'for'-loop concurrently (potentially over multiple machines in a cluster). So in my experience there was a bit of latency for the query to execute, but then it executes faster and on much larger datasets than regular JS could handle. Just like how you could easily manipulate tabular data using numpy or pandas (or excel), but SQL allows you to do it declaratively, which has benefits in some cases.
- mr_toad 5y ago
  CouchDB has been running distributed Map/Reduce queries on JSON data for over a decade. It’ll be interesting to see how this compares.
marstall 5y ago
it's just less code - instead of writing a series of buggy loops with null checks and string concatenations all over the place, you just writing a line of declaration and it deals with all that for you.
ghislainfourny 5y ago
Thank you for your comment. The motivation for JSONiq and RumbleDB is discussed in this recent paper, the core argument is data independence: https://arxiv.org/abs/1910.11582v3 https://arxiv.org/abs/1910.11582v3 JSONiq is a functional language and thus makes it easy to scale to collections that have billions of objects. A notable difference with JavaScript is that JSONiq has the FLWOR expression, which is similar to, but more generic than, a SQL statement.

markstos 5y ago

Good points. JSON processing tools I find helpful in addition to JavaScript include Gron aka "grep for JavaScript" ( https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron ), jq for querying, json_pp for pretty-printing and `bat` for syntax highlighting.

Mariehane 5y ago

This does some clever stuff in the background, e.g. query optimization and performing the computations of a 'for'-loop concurrently (potentially over multiple machines in a cluster). So in my experience there was a bit of latency for the query to execute, but then it executes faster and on much larger datasets than regular JS could handle. Just like how you could easily manipulate tabular data using numpy or pandas (or excel), but SQL allows you to do it declaratively, which has benefits in some cases.

mr_toad 5y ago
CouchDB has been running distributed Map/Reduce queries on JSON data for over a decade. It’ll be interesting to see how this compares.

marstall 5y ago

it's just less code - instead of writing a series of buggy loops with null checks and string concatenations all over the place, you just writing a line of declaration and it deals with all that for you.

ghislainfourny 5y ago

Thank you for your comment. The motivation for JSONiq and RumbleDB is discussed in this recent paper, the core argument is data independence: https://arxiv.org/abs/1910.11582v3 https://arxiv.org/abs/1910.11582v3 JSONiq is a functional language and thus makes it easy to scale to collections that have billions of objects. A notable difference with JavaScript is that JSONiq has the FLWOR expression, which is similar to, but more generic than, a SQL statement.