Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Q: A faster re-implementaiton of jq written in Reason Native/OCaml

github.com

Post reply on HN
Print view View original

81–90 of 196 posts

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#81

Post by jeffbee »

caymanjim wrote: post #77
jeffbee wrote: post #54

Earlier quoted context omitted.

Yes, I don't understand how people end up with assertions that the filename is a require argument. At least we've got /dev/stdin or /proc/self/fd/0 as workarounds.

Much Unix software today is written by people who really don't appreciate or understand Unix. It leads to things like Homebrew (early on, at least) completely taking over and breaking /usr/local; to command-line utilities using a single dash (-) precending both short and long option names (granted, --long-opts is a GNUism, but it's a well-established standard); commands that output color by default even when the outp…

The `go` program uses -longopts and I think it would be hard to argue that Rob Pike lacks an appreciation of Unix traditions.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#82

Post by aasasd »

For everyone pining for a Jq with a different syntax: I have a bunch of links to alternatives collected, you might want to try some of them (some may be for different things than JSON):

https://github.com/fiatjaf/awesome-jq

https://github.com/TomConlin/json2xpath

https://github.com/antonmedv/fx

https://github.com/fiatjaf/jiq

https://github.com/simeji/jid

https://github.com/jmespath/jp

https://github.com/cube2222/jql

https://jsonnet.org

https://github.com/borkdude/jet

https://github.com/jzelinskie/faq

https://github.com/dflemstr/rq

Personally I think that next time I might just fire up Hy and use its functional capabilities.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#83

Post by davesnx »

toastal wrote: post #8

Are we sure it should get a single-letter 'q' binary name though? Docs seem to point that it's short for 'query-json'? Why not call it 'query-json' and let the user decide that as a shell alias or whatever. Even the ubiquitous 'ls' and 'cd' are two characters.

Renamed already :D

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#84

Post by jeffbee »

davesnx wrote: post #80
jeffbee wrote: post #47

1) refuses to operate on stdin; requires a filename argument, which is so irritating. 2) doesn't accept values that jq accepts % time jq -r '[expression]'

Nothing that can be fixed later?

Probably. You tell us :=)

The incompatibility is apparently due to the fact that jq is happy with a concatenation of JSON objects and q is not. For example {'foo':1}{'foo':2} as opposed to [{'foo':1},{'foo':2}]

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#85

Post by benibela »

mkesper wrote: post #13

I'd long for such a tool with a better comprehensible query language.

There is XPath 3.1: https://www.w3.org/TR/xpath-31/#id-lookup

It is more verbose, like you get the size of something with array:size or map:size functions, so it is more readable

I am implementing it in Xidel 0.9.9+: http://www.videlibri.de/xidel.html

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#87

Post by aasasd »

vasergen wrote: post #38

The speed is not concern for me. I am wondering if there something better than `jq` in terms of syntax. Whenever I want to get something more that just prettify json output in the console or simply get value by specific field name I have a problem, for me it is just difficult to remember jq syntax without looking into history. As well have in my notes links to examples like this one https://mosermichael.github.io/jq-…

Might want to take a look at some of these alternatives: https://news.ycombinator.com/item?id=24470715

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#89

Post by kilroy123 »

f311a wrote: post #52
jeffbee wrote: post #47

1) refuses to operate on stdin; requires a filename argument, which is so irritating. 2) doesn't accept values that jq accepts % time jq -r '[expression]'

That's super weird, I think most people use jq for bash pipelines.

Probably true but I use it regularly in the automation app huginn.

https://github.com/huginn/huginn

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#90

Post by davesnx »

jeffbee wrote: post #84
davesnx wrote: post #80

Earlier quoted context omitted.

Nothing that can be fixed later?

Probably. You tell us :=) The incompatibility is apparently due to the fact that jq is happy with a concatenation of JSON objects and q is not. For example {'foo':1}{'foo':2} as opposed to [{'foo':1},{'foo':2}]

Sure, it's a missing feature "," creates 2 spins of the filter.

I certantly didn't use it, but I see where it's useful, will implement it soon.

Post reply on HN