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

Jaq – A jq clone focused on correctness, speed, and simplicity

github.com

Post reply on HN
Print view View original

101–110 of 254 posts

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#101

Post by IshKebab »

Exoristos wrote: post #24
wewtyflakes wrote: post #18

Earlier quoted context omitted.

How does this relate to navigating structured documents? Even if you use XML, presumably you will want to programmatically navigate/query it at some point.

That's my whole point. The tools for navigating, transforming, streaming, parsing, etc. XML are genuinely terrific, like nothing else, and it's demoralizing to see younger devs throw it all away because they prefer not to have to learn anything with more than trivial complexity.

It's not really because they don't want to have to learn it, it's because XML is fundamentally the wrong data model for most data. JSON is great because it matches the object structure used in 99% of programming languages - for JS it is the object structure.

Find me a programming language where objects have attributes, the order of members is significant and can be interleaved, everything is stringly typed etc...

It's a shame because I agree the tooling for XML is still better than JSON. But not better enough that it's worth fighting the data model mismatch.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#102

Post by matt_kantor »

necubi wrote: post #94
lopatin wrote: post #90

Regarding correctness, will it display uint64 numbers without truncating them? That's my biggest pet peeve with jq currently.

Unfortunately JSON numbers are 64 bit floats, so if you're standards compliant you have to treat them as such, which gives you 53 bits of precision for integers. Also hey, been a while ;) Edit: I stand corrected, the latest spec (rfc8259) only formally specifies the textual format, but not the semantics of numbers. However, it does have this to say: > This specification allows implementations to set limits on the ran…

I'm being pedantic here, but JSON numbers are sequences of digits and ./+/-/e/E. Whether to parse those sequences into 64-bit floats or something else is left up to the implementation.

However what you say is good practice anyway. The spec (RFC 8259) has this note on interoperability:

> This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#103

Post by notatoad »

loudmax wrote: post #6

I applaud this project's focus on correctness and efficiency, but I'd also really like a version of `jq` that's easy to understand without having to learn a whole new syntax. `jq` is a really powerful tool and `jaq` promises to be even more powerful. But, as a system administrator, most lot of the time that I'm dealing with json files, something that behaved more like grep would be sufficient.

there's got to be some syntax though. jq does a unique function that isn't defined in any other syntax. i'm with you, the jq syntax is weird and sometimes difficult to understand. but the replacement would just be some different syntax.

these little one-off unique syntaxes that i'm never going to properly learn are one of my favourite uses of chatGPT.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#105

Post by rdtsc »

necubi wrote: post #94
lopatin wrote: post #90

Regarding correctness, will it display uint64 numbers without truncating them? That's my biggest pet peeve with jq currently.

Unfortunately JSON numbers are 64 bit floats, so if you're standards compliant you have to treat them as such, which gives you 53 bits of precision for integers. Also hey, been a while ;) Edit: I stand corrected, the latest spec (rfc8259) only formally specifies the textual format, but not the semantics of numbers. However, it does have this to say: > This specification allows implementations to set limits on the ran…

> Unfortunately JSON numbers are 64 bit floats, so if you're standards compliant you have to treat them as such,

Are you sure? Looking at https://www.json.org/json-en.html I don't see anything about 64 bit floats.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#106

Post by sillysaurusx »

sigmonsays wrote: post #104

why not contribute to the existing jq project instead of starting a new one? We have so many json query tools now it's insane.

Fun, of course. Existing projects are boring almost by definition. And this is volunteer work.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#107

Post by lopatin »

necubi wrote: post #94
lopatin wrote: post #90

Regarding correctness, will it display uint64 numbers without truncating them? That's my biggest pet peeve with jq currently.

Unfortunately JSON numbers are 64 bit floats, so if you're standards compliant you have to treat them as such, which gives you 53 bits of precision for integers. Also hey, been a while ;) Edit: I stand corrected, the latest spec (rfc8259) only formally specifies the textual format, but not the semantics of numbers. However, it does have this to say: > This specification allows implementations to set limits on the ran…

I thought the JSON spec says that numbers can have an arbitrary amount of digits.

Also, what!! Hey! Miss you man.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#109

Post by soulbadguy »

jjeaff wrote: post #99
gigatexal wrote: post #50

It's so awesome when projects shout out other projects that they're similar to or inspired by or not replacements for. I learned about https://github.com/yamafaktory/jql from the readme of this project and it's what I've been looking for for a long time, thank you! That's not to take away from JAQ by any means I just find the JQ style syntax uber hard to grokk so jql makes more sense for me.

Nice find. I think I'll try it out. Although I was hoping for a real SQL type experience. I don't understand why no one just copies SQL so I can write a query like "SELECT * FROM $json WHERE x>1". Everyone seems to want to invent their own new esoteric symbolic query language as if everything they do is a game of code golf. I really wish everyone would move away from this old Unix mentality of extremely concise, yet…

While i agree about the general sentiment on preferring well defined and explicit standard as opposed to "cute" custom made languages. In this case i am not convince that SQL would be the best candidate for querying nested structures like JSON.Something like xpath maybe.
Post reply on HN