I switched to jless and never looked back. The user interface is miles ahead of everything else
Jaq – A jq clone focused on correctness, speed, and simplicity
121–130 of 254 posts
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#122Regarding correctness, will it display uint64 numbers without truncating them? That's my biggest pet peeve with jq currently.
I believe this has improved in jq 1.7: https://github.com/jqlang/jq/releases/tag/jq-1.7
> Use decimal number literals to preserve precision. Comparison operations respects precision but arithmetic operations might truncate.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#123why not contribute to the existing jq project instead of starting a new one? We have so many json query tools now it's insane.
One reason to do this is that often performance improvements involve architectural overhauls that maintainers are unlikely to approve of.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#124Earlier quoted context omitted.
I like textql [0] better for this use case, as it's simpler in my mind. [0] https://github.com/dinedal/textql
textql doesn't seem to work with JSON. I think the grandparent comment meant that the data was in a table of sorts, represented in JSON.
Ah, you're right. TextQL combined with Miller would be closer, but DuckDB can do the same things all in one. Always good to have a variety of tools to choose from.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#125This language must be the spiritual successor of Perl
I inherited some piece of code that made use of an extremely long and complicated jq script. I simply gave up understanding the whole thing, and restored the balance in the universe by rewriting it in Perl.
I know perl is useful. I know it's going to help me. It seems like you can get away with a quick perl script whereas a python script would attract scrutiny.
But it's such a painful language to look at.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#126jq have been in my toolbox since a while it’s a very great tool. But yet another query language to learn, jaq seems identical on that. I think that’s where LLMs can help a lot to make it easier for adoption, I started a project on that note to manipulate the data just with natural language, https://partial.sh ‘cat’ your json file and describe what you want I think should be the way to go
I usually avoid those types of tools. It looks way too fragile and the examples look a bit magical. Do you think it's stable and easy to use?
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#127Earlier 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…
SQL is built for relational/tabular data, JSON is not relational and usually not tabular.
Well there is nothing saying you can't put relational data in json format.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#128Earlier quoted context omitted.
Found the Frenchmen :) Yes they're slightly different in theory, but not in any way that would prohibit mutual understanding. Besides, if you're telling anyone about this library you're most certainly going to spell it out anyways.
I'm American and pronounce Jacques and Jack the way they described. If someone said [ʒak], I would transcribe it as Jacques, and if someone said [dʒæk], I would transcribe it as Jack. It may be a French name, but it's not very foreign. (If I heard [dʒak], I would assume the speaker is British and transcribe it as Jack). I was confused reading people say that Jacques is pronounced the same as Jack, so it does seem lik…
I’d say the amount of time before that sneak edit from Jacques to Jack lends credibility my claim of the two’s “essential interchangability”.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#129It'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…
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 should obsess over the opposite: molding our mind to think more like the machine. This keeps a lot of things simple, uncomplicated, and flexible.
Does a painter wish for paints that were more like how he wanted them to be? Sure, but at the end of the day he buys the same paint everyone else does and learns to work with his medium.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#130Earlier quoted context omitted.
The other options are C, C++, Go, and maybe Ada or Zig, though I haven't seen many CLI tools written in those two in practice. In practice, it seems like Go, Rust, and C++ are the preferred languages for newer CLI tools, although I have no data; my conclusion is based on my general perception. Older ones, C and Perl.
I don't think many people would choose to start writing a new CLI in C++. That's just making things difficult for yourself. There are some domains where I might still pick C++ over Rust - especially games and GUIs. The Rust ecosystem for those hasn't matched C++ yet. But not for a CLI app. Especially one like this that doesn't have any difficult dependencies.
You may be right. There are few new-ish C++ CLI tools that I can think of. I don't know why I said it.