Faster and simpler with the command line: deep-comparing JSON files with jq

Post by dang » Sat, Dec 08, 2018, 8:21 AM UTC

johnjohnsmith wrote: post #36

orf wrote: post #18

Earlier quoted context omitted.

CSV is hardly an easy format to parse, or really produce. There is no CSV standard, and I bet lyrics contain all kinds of weird characters that makes choosing a separator hard. Newline JSON is a fine interchange format for this, and the only advantage I can see for CSV is you can load it into a database in one command. Which begs the question as to why use a database at all for a simple one-off diff, when there are m…

Oh, I see: you probably didn't know that CSV formats is also means character separated values, and can actually use non-printing ASCII characters as delimiters. You didn't think I actually meant commas did you? I guess your experience with character separated value files is very limited. But my point was to illustrate if record fields are consistent you don't need a heavyweight solution like JSON... and you clearly m…

Post by cryptonector » Mon, Dec 17, 2018, 10:44 PM UTC

JulianMorrison wrote: post #88

cryptonector wrote: post #24

Earlier quoted context omitted.

jq is a C program, yes, but jq programs are interpreted. Because jq is a dynamically-typed language, it wouldn't be easy to compile it to object code that would run too much faster than the byte-interpreted version (though it would still run faster). As you say, jq's power is that it is an expressive language, and it's much much easier to write jq programs that work than it is to write C/C++ programs as needed that d…

The interpreted language is just the setup phase for a pipeline of compiled-in data transformations.