Live data from Hacker News

Zq: An easier and faster alternative to jq

brimdata.io

101–110 of 237 posts

Re: Zq: An easier and faster alternative to jq

#101
post #88

Earlier quoted context omitted.

Same issue. However, I do successfully rely on using ctrl-r a lot to search prior invoked commands. And have a few core aliases that I've cobbled together....

Here because.... I didn't know of ctrl-R. What a life changer (although I had an alias for "hg" to "history | grep" :) )

Please check FZF [1] and it’s integration with ctrl-r. It’s a huge productivity boost and I cannot live without it.

[1] https://github.com/junegunn/fzf

Re: Zq: An easier and faster alternative to jq

#102
post #99

Okay, so I'm a big scripter and not much of a programmer and I definitely have found jq to be mostly worthless to me; but it also looks like zq doesn't much help? Seems to me that if you're in a shell, then you should be "shell-like." There should not be much of a learning curve at all, and when in doubt, try to behave like other shell tools, in a Unix way way. Make pipe behavior generally predictable, especially for…

Could you help me understand what your usecases are, and where jq/zq fall short? I find the tools useful for e.g. curl'ing a request with a JSON format into, and then mapping/filtering/reducing the content into what I want. It seems pretty unix-y to me, but I'm curious what the shortcomings are. For instance, could you give an example where the pipe behavior is unpredictable?

Re: Zq: An easier and faster alternative to jq

#103
post #6

Since no one seems to know about it, jq is described in great detail on the github wiki page [0]. That flattens the learning curve a lot. It's not as arcane as it seems. The touted claim that is fundamentally stateless is not true. jq is also stateful in the sense that it has variables. If you want, you can write regular procedural code this way. Some examples [1] The real problem of jq is that it is currently lackin…

> It's not as arcane as it seems. The issue with jq is that I use it maybe once a month, or even less. The syntax is "arcane enough" that I keep forgetting how to use it because I use it so sporadically. In comparison awk – which I also don't use that often – has a much easier syntax that I can mostly remember. Not entirely convinced by the zq syntax either though; it also seems "arcane enough" that I would keep forg…

I wonder if someone tried to use plain JS as a filtering language? It would be more verbose but it would be easy to remember. For example:

   [1,2,3] | js "out = 0; for (const n of this) out += n"
That would print "6". `out` would be a special variable you write to to print the result, and `this` would be the input.

Re: Zq: An easier and faster alternative to jq

#104

Whenever jq comes up I feel obligated to mention 'gron'[1]. If all you're doing is trying to grep some deeply nested field, it's way easier with gron, IMHO. [1] https://github.com/tomnomnom/gron

For a moment I thought that this is `glom`, which is also a tool I can recommend if you need to be doing any json processing in python (comes with a cli too). It does have a relatively steep learning curve for the advanced features, but does allow you to do interesting things like concisely write recursive parsers in the mini-dsl Glom provides.

https://glom.readthedocs.io/en/latest/

Re: Zq: An easier and faster alternative to jq

#105
post #42
post #20

These guys must really hate functional programming. I can see where jq might confuse someone new to it, but their replacement is irregular, stateful, still difficult, and I don't even see variable binding or anything. jq requires you to understand that `hello|world` will run world for each hello, passing the world out values to either the next piped expression, the wrapping value-collecting list, or printing them to…

No kidding! This part in particular jumped out at me: > To work around this statelessness, you can wrap a sequence of independent values into an array, iterate over the array, then wrap that result back up into another array so you can pass the entire sequence as a single value downstream to the “next filter”. This is literally just describing a map. A technique so generally applicable and useful that it's made its w…

In fact, jq already has `map`, which would replace the article's pattern of `[.[]|add]` with `map(add)`. It is defined as such:

    def map(f): [.[] | f];
Many built-in functions in jq are implemented in jq, in terms of a small set of core primitives. The implementations can be inspected in builtin.jq.

https://github.com/stedolan/jq/blob/master/src/builtin.jq#L3

Re: Zq: An easier and faster alternative to jq

#106
post #63

Why all the hate HN? I feel the author makes his case clearly, then presents an alternative. Underneath all this is a ton of work, for which I applaud OP. It may not scratch your particular itch, but come on! Being an ass on HN is a choice. It happens far too often, and I wish everyone would just dial it back.

I don't see hate for the project here.

I see criticism for the way they're trying to position it as easier than jq when it's just different than jq.

It looks like a cool project on its own and doesn't need to describe jq as confusing to make that point.

Re: Zq: An easier and faster alternative to jq

#108
In the theme of jq alternatives, there is fx[1] which has an interactive view and supports querying JSON in Javascript, Python and Ruby. It used to be a node CLI but was recently rewritten in golang[2]

[1] https://github.com/antonmedv/fx

[2] https://twitter.com/antonmedv/status/1515429017582809090

Re: Zq: An easier and faster alternative to jq

#109
post #25
post #6

Since no one seems to know about it, jq is described in great detail on the github wiki page [0]. That flattens the learning curve a lot. It's not as arcane as it seems. The touted claim that is fundamentally stateless is not true. jq is also stateful in the sense that it has variables. If you want, you can write regular procedural code this way. Some examples [1] The real problem of jq is that it is currently lackin…

I didn't realize jq was missing a maintainer, it's one of my most used CLI tools.

In this case it doesn't seem too critical? It means jq remains stable, which is probably what should happen once a tool like this gets a lot of users.

Re: Zq: An easier and faster alternative to jq

#110
post #77

Earlier quoted context omitted.

> It's not as arcane as it seems. The issue with jq is that I use it maybe once a month, or even less. The syntax is "arcane enough" that I keep forgetting how to use it because I use it so sporadically. In comparison awk – which I also don't use that often – has a much easier syntax that I can mostly remember. Not entirely convinced by the zq syntax either though; it also seems "arcane enough" that I would keep forg…

Interesting, for me it's the exact opposite. I've tried a couple of times to get into awk, but still find the syntax arcane.

I don't know; I wouldn't presume to tell you what you do or don't find arcane, but once I understood the somewhat unusual flow of awk ("for every line, check if the line matches this condition, and if it does run this block of code") I found it's quite easy to work with. It's "arcane" in the sense that it has an implicit loop and that it's a specialized language for a very limited class of problems, but I found that for this limited class of problem it's surprisingly effective.
Post reply on HN