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

121–130 of 196 posts

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

#121

Post by benibela »

jeffbee wrote: post #109
benibela wrote: post #85

Earlier quoted context omitted.

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

XPath is really useful and `xmlstarlet` is/was jq before jq existed. These days it's relatively rare to get data in XML instead of JSON, though.

This is about JSON

xmlstarlet supports XPath 1, but the W3C did not stop there. They made XPath 2 featuring variables, lists and regular expressions, XPath 3 featuring higher order function, and finally XPath 3.1 featuring JSON support.

For example,

     echo '[{"a": 1}, {"a": 2, "b": 3}, {"c": 4}]' | xidel - -e '?*?a!(. * 100)'
will print 100 and 200.

Or the same with a verbose syntax:

    echo '[{"a": 1}, {"a": 2, "b": 3}, {"c": 4}]' | xidel - -e 'for $obj in array:flatten(.) return map:get($obj, "a")  * 100'

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

#122

Post by ilikepi »

derefr wrote: post #101
caymanjim wrote: post #77

Earlier quoted context omitted.

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…

Tangent: Homebrew itself doesn’t really choose to take over /usr/local; rather, it just accepts that there exists POSIX software that is way too hard for most machines to compile, and so must be distributed precompiled; and yet where that precompilation implies a burning-in of an installation prefix at build time, which therefore cannot be customized at install time. And so that software must be compiled to assume so…

> You have always been able to customize Homebrew to install at a custom prefix, e.g. ~/brew. It’s just that, when you do that...

...and then try to build something entirely sensible like Postgres, but hours of fiddling with different XCode versions and compiler flags still lead to a dead end of errors, you're stuck because you're running an unsupported configuration.

I still don't understand how the PG bottles for Mojave can be built.

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

#123

Post by bfrydl »

thatjamesdude wrote: post #106
bfrydl wrote: post #97

Earlier quoted context omitted.

I would argue that Go's design as a whole is characterized by an attitude of ignoring established ideas for no other reason than that they think they know better.

Something being established is not a grand argument for it's usage. The reasons it got established are relavent, and if you feel the end result of said establishment is obtuse or inane, why would you use it? That's not to say Go's decisions to toss some established practices are "wise" or "sagely", just that broad acceptance is not a criteria they seemed concerned with. Which is fine. >they think they know better. It…

Sure, there's nothing that says established practice is better. That is not, in my opinion, a good defense of Go which makes many baffling design decisions. Besides, an appeal to the authority of Rob Pike is surely not a valid defense if mine is not a valid criticism.

I'm (perhaps unfairly) uninterested in writing out all the details, but “they think they know better” is because I see Go as someone's attempt to update C to the modern world without considering the lessons of any of the languages developed in the meantime. And because of the weird dogmatic wars about generics, modules, and error handling.

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

#124

Post by dullgiulio »

Spivak wrote: post #67
f311a wrote: post #62

Earlier quoted context omitted.

Most people work on compressed JSON lines files. Sometimes they are stored on s3. Files do not give flexibility. When using jq, I can do a lot of things: aws s3 cp s3://bucket/file.json.gz - | zcat | head | jq .field | sort

Which is sorta-kinda the same thing as jq .field which is more annoying to type but works.

Redirection is not a parameter, meaning that would still not work with this Q tool.

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

#125

Post by jeffbee »

benibela wrote: post #121
jeffbee wrote: post #109

Earlier quoted context omitted.

XPath is really useful and `xmlstarlet` is/was jq before jq existed. These days it's relatively rare to get data in XML instead of JSON, though.

This is about JSON xmlstarlet supports XPath 1, but the W3C did not stop there. They made XPath 2 featuring variables, lists and regular expressions, XPath 3 featuring higher order function, and finally XPath 3.1 featuring JSON support. For example, echo '[{"a": 1}, {"a": 2, "b": 3}, {"c": 4}]' | xidel - -e '?*?a!(. * 100)' will print 100 and 200. Or the same with a verbose syntax: echo '[{"a": 1}, {"a": 2, "b": 3},…

That's news to me. Very cool actually. It's not far from jq on speed, either. Looks like you are the maintainer of this tool, so thanks!

  ~/xidel % time ./xidel - -e '?SitusAddress!(.)'

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

#126

Post by choward »

jonemi wrote: post #99

I used to be a regular user of jq, but I was never parsing very large JSON. I now do what I used to do with jq in my browser's developer tools console. Map and filter are far more familiar than jq's syntax where I found myself referring to the documentation most of the time. I'm sure other people have use cases where the browser wouldn't meet their needs, but for me, I find jq unnecessary.

Writing a script? I'm not going to have my script open a web browser so I can attempt to interact with a web console.

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

#127

Post by yawaramin »

ashtonkem wrote: post #79
f311a wrote: post #52

Earlier quoted context omitted.

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

My most common jq usage is to copy and paste some json into quotes to make it easier to read. My second most common action is to chain curl and jq together. A replacement for jq that doesn’t use stdin is literally useless to me.

I think at least two people in the thread pointed out that you can use /dev/stdin as a file.

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

#128

Post by monadic2 »

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…

People often complain about homebrew's use of usr local without articulating what is lost.

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

#129

Post by jraph »

dullgiulio wrote: post #124
Spivak wrote: post #67

Earlier quoted context omitted.

Which is sorta-kinda the same thing as jq .field which is more annoying to type but works.

Redirection is not a parameter, meaning that would still not work with this Q tool.

This is not a simple redirection. cmd So, this should work :-)

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

#130

Post by monadic2 »

yawaramin wrote: post #127
ashtonkem wrote: post #79

Earlier quoted context omitted.

My most common jq usage is to copy and paste some json into quotes to make it easier to read. My second most common action is to chain curl and jq together. A replacement for jq that doesn’t use stdin is literally useless to me.

I think at least two people in the thread pointed out that you can use /dev/stdin as a file.

It's more than a little strange that isn't default behavior out of the box without specifying input. How do the authors think jq is used?
Post reply on HN