Comment by aasasd | Hacker News Reader

Comment by aasasd | Hacker News Reader

Every time I try to do something involved with jq (i.e. more than a couple commands deep) and inevitably end up wandering through the manual, I get a persistent feeling that jq could be cleaned up quite a bit. That it either has structure throughout that I fail to grasp, or that it's really rather disorganized and convoluted in places. This is exacerbated by me never being able to find anything in the manual without skimming half of it each single time.

E.g.:

Filtering and transforming objects by reaching a few levels deeper in them seems to be way easier to slap together in Python's list comprehensions or some functional notation. Stuff like [{ * * x, qwe: x.qwe*2} for x in a.b if x.y.z == 1].

Add nested lists to the above, and I can spend another fifteen minutes writing a one-liner (i.e. `a` is a list of objects with lists in some field).

I once had to deal with a conditional structure where a field might be one object or a list of them. Hoo boy.

Every time I want to check the number of entries my filters print out, I need to wrap them in an array. Repeat this a couple dozen times during writing a complex query. Weirdly, this is where strict structure gets in the way―and while I understand the reasoning, I feel that something could be done for such basic need. (Like, aggregate filters should be able to aggregate instead of acting on individual items? Maybe it's already in the language, but I'm not in the mood to go over the manual again.)

Variables seem to be bolted on as an afterthought, or at least the syntax doesn't exactly accommodate them. Meanwhile, they're necessary to implement some filters omitted in the language. Compare that to Lisp's simple `(let)`. IIRC the manual also says that jq has some semblance of functions, but I'm afraid to think about them with this syntax.

I like the idea a lot, but execution not so much. Frankly I'll probably end up throwing together a script in Lumo or something, that will accept Lisp expressions and feed JSON structure to them. (I'd use Fennel, but JSON has actual null while Lua... doesn't.)

Btw, I have pretty much the same sentiment about Git. Git structures, great. Git tools, oy vey. Maybe I need Lisp for Git, or at least Python for Git.

Personally I prefer https://github.com/jmespath/jp - it has a bit saner syntax based on an actual standard (at least for me it's easier to remember than jq).

And perhaps more importantly it doesn't mess with your numbers! Some other comment mentioned doubles, but I had a problem with Longs, jq would silently truncate them when they became to large to fit inside a float (I was working with random Long numbers used as secrets in some schema so it happened quite quickly in my use case).

Thanks for this; for the few cases/year I need something like `jq`, I just find its selector syntax too hard to remember (seems a common theme). `jp` seems way more usable.

Hey, just wanted to say that this comment made me create jql, an alternative to jq with a lispy syntax: https://github.com/cube2222/jql

Thanks for the inspiration!

> I like the idea a lot, but execution not so much. Frankly I'll probably end up throwing together a script in Lumo or something, that will accept Lisp expressions and feed JSON structure to them. (I'd use Fennel, but JSON has actual null while Lua... doesn't.)

This may come off as a little snarky but, you should totally give this a try and post the result on HN.

I say this because I both love jq for its functionality, but also have deep frustrations with wrangling it. I really encourage any attempts to improve it.

There's definitely room for a better jq - I would 100% try a version of it that was as simple to install, use, and just had a slightly easier to use language.

It would be very easy to do in Lua/Fennel, afaik. The problem is that Lua is so trigger-happy about `nil` that it doesn't distinguish nil's presence from absence, which won't do for JSON.

Now, I could attempt doing this in ClojureScript, but I'll get derailed to thinking about ClojureScript's inseparable conjoinery to Clojure and JVM, even if manifested in Lumo only as inexplicable boilerplate, and that gives me depression. Also Lua's start-up is faster than even bare Node.

Hy is probably the optimal choice. There's not even much to write: I can as well just spin up Hy's repl and read JSON in it. Maybe will need a few helper functions to save me from verbosity.

I agree. jq makes the easy stuff easy, but the syntax gets weird pretty quickly.

You might like fx [0]. Run on its own, it’s a command line JSON browser (you can even click on items to expand/collapse them), and you can also write little JS one-liners to do stuff like map over an array and transform the items.

Something like this, to extract the name from an array of users, for instance:

fx users.json ‘u => u.name’

0: https://github.com/antonmedv/fx

(Still) too damn complicated, yes.

I use it 1-2 times a month and always have to RTFM.

Yeah! I'm constantly RTFM for stuff that feels like it ought to be rather basic! That said, I love jq.

Reply on news.ycombinator.com