6 ms·

> I hate that the jq command is always some indecipherable string in the middle of the script It might be worthwhile to just learn how jq works. At the end of

> I hate that the jq command is always some indecipherable string in the middle of the script It might be worthwhile to just learn how jq works. At the end of the day, you need to learn some language to parse json. I hate DSLs too, but I cannot think of anything as useful and concise as jq. > but that ends up being at least as nasty as the JQ script That's exaxtly why jq is so nice. Nice alternatives just don't exist

speed_spread 3y ago
Something not having alternatives doesn't make it necessarily nice. It's okay to wish for better even if you have something that works.
- ustolemyname 3y ago
  I think in this case "better" reduces to convincing the upstream data source to not use json. Putting that frustration on jq seems like a case of transference.
  - spion 3y ago
    Or maybe jq does have some design flaws.
  - Nullabillity 3y ago
    And now you've turned a JSON traversal problem into a parsing problem.. congratulations?
- deleted 3y ago
  [deleted]
- hn92726819 3y ago
  > Something not having alternatives doesn't make it necessarily nice Of course not, but compared to every alternative today, jq is eons better than everything else. It's conciseness, ease of use, ease of learning all make it awesome. So as of right now, it is the nicest thing to use by far. Personally though, I don't think I do wish for better. Jq is missing nothing that I want.
p-e-w 3y ago
> That's exaxtly why jq is so nice. Nice alternatives just don't exist Write a simple Python script, parse JSON into native objects, manipulate those objects as desired with standard Python code, then serialize back into JSON if necessary. Voila, you have a readable, maintainable, straightforward solution, and the only dependency (the Python interpreter) is already preinstalled on almost every modern system. Sure, you may need a few more lines of code than what would be possible with a tailor-made DSL like jq, but this isn't code golf. Good code targets humans, not "least possible number of bytes, arranged in the cleverest possible way".
- hnben 3y ago
  > Sure, you may need a few more lines of code than ... jQ integrates very nicely into bash script. Especially in between pipes a short&simple jq-snippet can work wonders for readability of the overall script. On the other hand, if the bash script becomes too complex it may be a good idea to replace the entire bash script with python (instead of just the json-parsing-part)
  - viraptor 3y ago
    > Especially in between pipes a short&simple jq-snippet Many of them are not short and simple though. And each time you do a some transformation, you pretty much need to go in/out of jq at each step of it want to make some decisions or get multiple types of results without processing the original multiple times.
  - p-e-w 3y ago
    > a short&simple jq-snippet can work wonders for readability of the overall script. ... if the reader happens to be familiar with the niche language "jq". Otherwise, you may as well have put some Akkadian cuneiform in there.
    - Ekaros 3y ago
      So awk or sed or maybe even grep? jq seems slightly better than those...
ahoka 3y ago
What about JSONPath?
- mdaniel 3y ago
  It may be fine for hello-world stuff, but how would one JSONPath this? echo '[{"name":"_skip"},{"name":"alpha"},{"name":"_other"}' | \ jq '[ .[] | select(.name|test("^_.*")|not) | . ]' The same is roughly true for JMESPath, also, although at least it does actually try to allow projections and some limited functions
  - ahoka 3y ago
    I believe like this. $[?(@.name =~ /[^_].*/)]
    - mdaniel 3y ago
      Interesting, I only knew about <https://goessner.net/articles/JsonPath/index.html https://goessner.net/articles/JsonPath/index.html> which makes no reference to =~ nor any such // syntax but it seems there's an IETF draft that is (a) an actual specification (b) includes more modern stuff like what you used: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-07.html#section-3.5.5.1-14 https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-07.... And, while whatever is powering https://jsonpath.com/ https://jsonpath.com/ does honor your syntax, albeit with an absolutely useless result: [ { "name": -1 }, { "name": -1 }, { "name": -1 } ] I found that `pip install jsonpath-ng` does not accept it nor mention it <https://github.com/h2non/jsonpath-ng/tree/v1.5.3?tab=readme-ov-file#extensions https://github.com/h2non/jsonpath-ng/tree/v1.5.3?tab=readme-...> so I think it's out on the bleeding edge or something
  - storoj 3y ago
    Is ".*" necessary? I think "^_" should be enough.
- hn92726819 3y ago
  I hadn't seen this before. At a quick glance, the syntax looks fine. Though I don't know what command line utility I'd need to use it. It makes me wonder how hard a translator from jq syntax to jsonpath would be... Then we could have our cake and eat it too.
jordibc 3y ago
I really like jq, but I think there is at least one nice alternative to it: jet [1]. It is also a single executable, written in clojure and fast. Among other niceties, you don't have to learn any DSL in this case -- at least not if you already know clojure! [1] https://github.com/borkdude/jet https://github.com/borkdude/jet

speed_spread 3y ago

Something not having alternatives doesn't make it necessarily nice. It's okay to wish for better even if you have something that works.

ustolemyname 3y ago
I think in this case "better" reduces to convincing the upstream data source to not use json. Putting that frustration on jq seems like a case of transference.
- spion 3y ago
  Or maybe jq does have some design flaws.
- Nullabillity 3y ago
  And now you've turned a JSON traversal problem into a parsing problem.. congratulations?
deleted 3y ago
[deleted]
hn92726819 3y ago
> Something not having alternatives doesn't make it necessarily nice Of course not, but compared to every alternative today, jq is eons better than everything else. It's conciseness, ease of use, ease of learning all make it awesome. So as of right now, it is the nicest thing to use by far. Personally though, I don't think I do wish for better. Jq is missing nothing that I want.

p-e-w 3y ago

> That's exaxtly why jq is so nice. Nice alternatives just don't exist Write a simple Python script, parse JSON into native objects, manipulate those objects as desired with standard Python code, then serialize back into JSON if necessary. Voila, you have a readable, maintainable, straightforward solution, and the only dependency (the Python interpreter) is already preinstalled on almost every modern system. Sure, you may need a few more lines of code than what would be possible with a tailor-made DSL like jq, but this isn't code golf. Good code targets humans, not "least possible number of bytes, arranged in the cleverest possible way".

hnben 3y ago
> Sure, you may need a few more lines of code than ... jQ integrates very nicely into bash script. Especially in between pipes a short&simple jq-snippet can work wonders for readability of the overall script. On the other hand, if the bash script becomes too complex it may be a good idea to replace the entire bash script with python (instead of just the json-parsing-part)
- viraptor 3y ago
  > Especially in between pipes a short&simple jq-snippet Many of them are not short and simple though. And each time you do a some transformation, you pretty much need to go in/out of jq at each step of it want to make some decisions or get multiple types of results without processing the original multiple times.
- p-e-w 3y ago
  > a short&simple jq-snippet can work wonders for readability of the overall script. ... if the reader happens to be familiar with the niche language "jq". Otherwise, you may as well have put some Akkadian cuneiform in there.
  - Ekaros 3y ago
    So awk or sed or maybe even grep? jq seems slightly better than those...

ahoka 3y ago

What about JSONPath?

mdaniel 3y ago
It may be fine for hello-world stuff, but how would one JSONPath this? echo '[{"name":"_skip"},{"name":"alpha"},{"name":"_other"}' | \ jq '[ .[] | select(.name|test("^_.*")|not) | . ]' The same is roughly true for JMESPath, also, although at least it does actually try to allow projections and some limited functions
- ahoka 3y ago
  I believe like this. $[?(@.name =~ /[^_].*/)]
  - mdaniel 3y ago
    Interesting, I only knew about <https://goessner.net/articles/JsonPath/index.html https://goessner.net/articles/JsonPath/index.html> which makes no reference to =~ nor any such // syntax but it seems there's an IETF draft that is (a) an actual specification (b) includes more modern stuff like what you used: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-07.html#section-3.5.5.1-14 https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-07.... And, while whatever is powering https://jsonpath.com/ https://jsonpath.com/ does honor your syntax, albeit with an absolutely useless result: [ { "name": -1 }, { "name": -1 }, { "name": -1 } ] I found that `pip install jsonpath-ng` does not accept it nor mention it <https://github.com/h2non/jsonpath-ng/tree/v1.5.3?tab=readme-ov-file#extensions https://github.com/h2non/jsonpath-ng/tree/v1.5.3?tab=readme-...> so I think it's out on the bleeding edge or something
- storoj 3y ago
  Is ".*" necessary? I think "^_" should be enough.
hn92726819 3y ago
I hadn't seen this before. At a quick glance, the syntax looks fine. Though I don't know what command line utility I'd need to use it. It makes me wonder how hard a translator from jq syntax to jsonpath would be... Then we could have our cake and eat it too.

jordibc 3y ago

I really like jq, but I think there is at least one nice alternative to it: jet [1]. It is also a single executable, written in clojure and fast. Among other niceties, you don't have to learn any DSL in this case -- at least not if you already know clojure! [1] https://github.com/borkdude/jet https://github.com/borkdude/jet