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

221–230 of 254 posts

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

#221

Post by trealira »

explaininjs wrote: post #92
trealira wrote: post #77

Earlier quoted context omitted.

It sounds like [a] to me, not [æ]. The a in the name Jacques is pronounced as in the word father . The a in the name Jack is pronounced as in cat.

As someone who has heard the name "Jack" pronounced by Americans many, many, many times in their life... that Jaques video sounds entirely in-range of the variety of pronunciations I hear for Jack.

Well, as one particular American, who has spoken to many, many other Americans in their life, I can only tell you what I think.

Something I find interesting is that Americans say the a in the word taco (a word borrowed from Spanish) with the a as in father, that is, [ɑː], but English people say the a as in cat, [æ]. Different dialects approximate the Spanish [a] differently.

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

#222

Post by lkuty »

nurettin wrote: post #95
stickfigure wrote: post #91

Congratulations! We're almost back to the basic functionality we used to have with XSLT.

To be fair, xslt is a lot more verbose than `map(.*2)`

A bit more verbose but you have the full power of XQuery with you. XSLT however is more verbose than that like you mentioned.

    for $price in json-to-xml(unparsed-text($file))/map/map/number[@key="price"]
    return $price+2
For the following JSON document:

    {
      "fruit1": {
        "name": "apple",
        "color": "green",
        "price": 1.2
      },
      "fruit2": {
        "name": "pear",
        "color": "green",
        "price": 1.6
      }
    }
The call to json-to-xml() produces this XML document:

    
    
       
          apple
          green
          1.2
       
       
          pear
          green
          1.6

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

#223

Post by sgt »

eyegor wrote: post #211
sgt wrote: post #209

The fact that jq takes almost a second to run on a Pi is crazy[0]. And the tool is written in C. [0] https://github.com/jqlang/jq/issues/1411

It was fixed in 2019 though? I don't understand your point. https://github.com/jqlang/jq/issues/1380

You are right. I stand corrected.

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

#224

Post by mmorearty »

Osiris wrote: post #208

I love the idea of jq but i use it infrequently enough that I have to search the manual for how to use their syntax to get what I want. Sadly 99% of what I do with jq is “| jq .”

Me too; but recently I used ChatGPT to just quickly me the jq syntax I needed: https://chat.openai.com/share/40b68d73-d2dd-412d-867f-9f375e...

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

#225

Post by never_inline »

antonvs wrote: post #204
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.

> I just find the JQ style syntax uber hard to grokk You're not alone. ChatGPT (3.5) is terrible at it also, for anything non-trivial. I'm not sure if that's because of the nature of the jq syntax, but I do wonder.

Well ChatGPT doesn't 'grok' anything, really..

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

#226

Post by hnlmorg »

pizza_pleb wrote: post #76
awayto wrote: post #32

Earlier quoted context omitted.

Is there anything out there like "SELECT * FROM " http:// ..."?

I think a query language would be great, with a way to subquery/chain data from previous requests (e.g. by jsonpath) to subsequent ones. The closest I’ve gotten is to wrap the APIs with GraphQL. This achieves joining, but requires strict typing and coding the schema+relationships ahead of time which restricts query flexibility for unforeseen edge cases. Another is a workflow automation tool like n8n which isn’t as st…

This is exactly what Murex shell does. It has lots of builtin tools for querying structured data (of varying formats) but also supports POSIX pipes for using existing tools like `jq` et al seamlessly too.

https://murex.rocks

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

#227

Post by suchar »

pestaa wrote: post #44
suchar wrote: post #28

Earlier quoted context omitted.

I'm not sure if there is any open source XSLT tool as complete as jq is for JSON. There is xsltproc but IIRC it does not support streaming scenarios (jq has some support for streaming processing) Though, personally, I prefer JSON. Probably due to superior tools (thanks to its popularity) and less-bloated syntax (it is somewhat easier for me to read raw JSON file than raw XML file).

Saxon is where it's at. When XSLT 3.0 tells a joke, it starts with "a JSON walks into a bar..." https://github.com/Saxonica/Saxon-HE

I do not see license in either repository and it seems that this tool only has 30 day evaluation tier for free. Anyway, using this means that you have dependency on a single vendor and you accept their future pricing changes.

Now compare this with JSON ecosystem

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

#228

Post by coldtea »

ClassyJacket wrote: post #196
throw555chip wrote: post #185

Earlier quoted context omitted.

I used Bard after trying unsuccessfully to decipher the wikipedia page and Bard says, according to IEEE 754, nan nan should return false (0)

I wish there was some version of Wikipedia for people who speak good English (not Simple English), but aren't assumed to already be experts on the topic. Technical articles are pretty much impenetrable.

So you basically wish for Wikipedia to also feature simplified explanations of technical topics.

I don't think "good English vs simple english" plays into this.

It's not like the problem for technical articles being impenetratable on Wiki is that Wiki doesn't have an intermediate level between expert-talk and simple english.

It's just that it doesn't have simple english explanations of some technical topics.

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

#229

Post by reportgunner »

pdntspa wrote: post #129
jjeaff wrote: post #99

Earlier quoted context omitted.

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…

Be the change you want to see. I personally don't understand why people aren't willing to learn instead. It's not hard to sit down and pick up a new skill and it's good to step out of one's comfort zone. I personally hate Powershell syntax, brevity is the soul of wit and PS could learn a thing or two from bash and "the linux way". We seem obsessed with molding the machine to our individual preferences. Perhaps we sho…

Yeah I don't understand why people aren't willing to learn SQL too.

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

#230

Post by majewsky »

sgt wrote: post #210
WhereIsTheTruth wrote: post #134

https://github.com/01mf02/jaq/blob/main/Cargo.lock That's a lot of dependencies..

How does that usually play out in the Rust ecosystem? Lots of dependencies tell me there's a huge risk of the dependencies becoming inherently incompatible with each other over time, making maintenance a major task. How will this compile in say, 2 years?

Because of the lockfile, it will use the same library versions when compiling again in the future. The main question for "will this compile" is whether the Rust compiler is sufficiently backwards-compatible, which (at least from my experience) it certainly is.

Also re "lots of dependencies": This is kind of unavoidable in Rust because the stdlib is deliberately very lean, and focuses on basic data structures that are needed for interop (e.g. having common string types is important for different libraries to work together with each other) or not possible to implement without specific compiler support (e.g. marker traits or boxing). Contrast this with Go where the stdlib contains things like a full-fledged HTTP server and regex engine. It's easy to build things in Go with a rather short go.mod file, but only because the go.mod file does not show all the stdlib packages that you're using.

Post reply on HN