Also the revolution of two-letter command names :/.
I mean, at least before one has proven a tool's ubiquitous use, use a longer name.
jq just got lucky but I don't think it was because of its name ;).
The Pretty JSON Revolution
41–50 of 159 posts
Re: The Pretty JSON Revolution
#42What if the JSON has multiple nested objects?
Re: The Pretty JSON Revolution
#43Please: { "colors": [ { "color": "black", "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red", "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow", "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green", "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan", "hex": "#0ff", "rgb": [ 0, 255, 255 ] }, { "color": "blue", "hex": "#00f", "rgb": [ 0, 0, 255 ] }, { "color": "magenta", "hex": "#f0f", "rgb": […
visidata shows it as:
color | hex | rgb ║
red | #f00 | [3] ║
black | #000 | [3] ║
yellow | #ff0 | [3] ║
green | #0f0 | [3] ║
cyan | #0ff | [3] ║
blue | #00f | [3] ║
magenta | #f0f | [3] ║
white | #fff | [3] ║
Re: The Pretty JSON Revolution
#44Funny coincidence for cli tool name and the Icelandic meaning:
https://en.wiktionary.org/wiki/oj#Interjection
Re: The Pretty JSON Revolution
#45Nicely done. First I've seen "SEN".
Treating the colons as white space, as you've done with the commas, will move you one step closer to The Correct Answer™.
Re: The Pretty JSON Revolution
#46Earlier quoted context omitted.
I would be a little nervous sorting the keys. I thought it was not too uncommon for parsers to treat them as an alist where order matters. I guess so long as it is a stable sort, no big deal?
Pretty printing JSON is mostly for developer consumption, I'm not sure how the pretty printed JSON would end up being fed automatically to another system? (I have actually encountered a order-dependent JSON-subset parser before, but to my mind, that code is broken)
Pretty JSON is still just JSON. It should work with any JSON parser. Of course if it is being fed from one system to another there is no need to make the JSON anything other than compact one line JSON. Pretty is for human consumption.
Re: The Pretty JSON Revolution
#47Also the revolution of two-letter command names :/. I mean, at least before one has proven a tool's ubiquitous use, use a longer name. jq just got lucky but I don't think it was because of its name ;).
Oj is actually pretty well known as a Ruby JSON parser. The OjG project is in the same family.
Re: The Pretty JSON Revolution
#48IMHO, this is what YAML is actually for.
YAML is “a superset of JSON”, yes, but there are two separate meanings to that:
• YAML has alternative syntactic sugar for expressing the same underlying JSON-equivalent semantics (sort of the same as Avro being canonically a binary compact expression of underlying JSON — in both cases, libraries for the codec expect JSON-encodable data structures as #encode input, and produce JSON-encodable data structures as #decode output)
• YAML has its own semantics (like node type annotations, or references) that JSON doesn’t have, such that documents that use these are no longer transposable into JSON.
I love bullet point #1. I hate bullet point #2.
Personally, I wish there was a name for the reduced subset of YAML that is still a “syntactic superset of JSON”, but which has none of the extended semantics of bullet-point #2.
Many systems that “consume YAML” already actually require their documents to be this “strictly-JSONifiable YAML”! Kubernetes, for example: it might seem to expose a YAML manifest API, but actually, internally, it does everything in JSON. All the resources in k8s etcd are stored in canonicalized JSON. The k8s controller just prettifies that JSON to YAML on its way out to you; and uglifies it back to JSON when you send it in. Which means that any YAML features that don’t survive that translation, can’t be used.
IMHO, if YAML hadn’t been designed with any extended semantics, but instead had strictly targeted being a “sugared alternative encoding of JSON”, I think everyone would have switched to sending YAML in place of JSON a long time ago. Browsers would have likely added YAML parsing as well.
But those added semantics are just so much extra work for everybody. Type annotations are source of so many vulnerabilities in programs that were unaware their input could “reach in and do things” through those types; and yet many YAML parser libs don’t have any flag to restrict them from decoding these type annotations (i.e. no way to “defuse the bomb.”) References change the entire way you have to write a YAML parser, disallowing some types of parsing grammar altogether, meaning you might no longer have access to the first-class parsing solution of your language runtime; meaning that for many runtimes, the YAML codec lib for that runtime is much slower — and memory-intensive! — than the JSON codec lib for the same runtime. Etc.
Honestly, if we could all agree on a name for “strict, JSONifiable YAML”, and create libraries that only parse/validate/accept that subset of YAML while rejecting the higher-level semantics, those libs—and that interchange format—would be immediately more popular than YAML. The time for this to happen hasn’t passed! We still have a chance!
Re: The Pretty JSON Revolution
#49The human style format reminds me of the default format of js-beautify [1]. We use it to get the "human-style" instead of the "One Line Per Node" for a project where we store json files in a git repo. That way the git diff is pretty easy to read and not bloated. Too bad, not many tools have the "human-style" option.
Re: The Pretty JSON Revolution
#50I would prefer one that aligned the like named keys, if it fits in screen. Makes it dead easy to scan the values. That said, it is just another pun on the text as art thing. In that it doesn't really scale, and you are going to upset someone by not having a codified tool for automatically doing this. (I don't recall seeing align-regex in any popular tool.)
Can you explain what you mean by "like named"? The sorting helps a lot but I'm always interested in additional features.
The current top comment is what I meant. On my phone, so couldn't put an example easily.