I agree, and you have a good point here, specially as system administrator, where you're likely to look at the data itself and output from the system. This happens in particular for structured logging, as it's fairly common to have JSON logging.

Although for configuration maybe YAML or even TOML are my preferred, having to "manually" write JSON is a pain.

JSON is likely the most widespread format, with `jq` definitely making it more usable.

My exception to this would be for formats with specific usages, like `protobuf` which has some machine-to-machine advantages over JSON. And even that has an option to convert to JSON.

So while JSON is good enough, at least for reading/parsing, other cases I'd say could benefit from other formats.

Agree wholeheartedly. Also, shout out to another JSON-reading/managing tool I stumbled on recently, https://jless.io/ - it even has keybindings for copying various bits out of the document you're navigating. (Eg: raw value, JSON value, path to value that you can then turn around and stuff into a 'jq' invocation, etc etc.)

JSON is often the least bad for complex data structures, but sometimes even simple data structures get turned into bad JSON. See https://www.datafix.com.au/BASHing2/2024-04-12.html

100% this. I do not think tools like jq are considered enough when people critique a format in some academic fashion

As for this part of the original tweet (toot?):

Repeating every verbose field name in each record, when the schema is flat,

well, I've seen JSON data in

   {"fields": ["name", "price", "amount", "date", "legal"],
    "data": [{"dog toy", 41.99, 11, 1724766809, true},
             {"aspirin", 0.99, 2000, 1724347831, false}, 
             ...]}

format which is awkward to use with jq, but one can use it if absolutely needs to.

Overly-specialized parsing of bespoke command output is the UNIX philosophy. It's pitiful that a data format made by taking a shitty programming language's syntax has become so popular. JSON can't properly encode integers of arbitrary length, and its processing is rife with edge cases different tools handle differently. Bencoding as used by BitTorrent is superior in every way. S-expressions are also better, but I'm not holding my breath for people to accept those.

If your program does use only a custom output format, I want there to be a really good reason why you did it, not just that you don't like the aesthetics of JSON.

This is an admission that the UNIX philosophy doesn't work, at all. I design custom formats because that is the only way to get total efficiency, although I'm referring to the on disk representation, as it's commonly called.

As Rob Pike says, no one likes gofmt's style, but we all like that everyone uses it.

In a Lisp Machine, Smalltalk system, and other better computers, everything is a language-level object, and no parsing is needed whatsoever. It's funny how that simple idea is so unpopular.

As sysadmin having properly formatted output for automations is great (so it won't break easily with another update just because of some formatting change). That's why I love FreeBSD approach with libxo https://wiki.freebsd.org/LibXo

e.g. w --libxo json | json_pp

{
  "uptime-information" : {
     "days" : 0,
     "hours" : 2,
     "load-average-1" : 0.22,
     "load-average-15" : 0.1,
     "load-average-5" : 0.15,
     "minutes" : 52,
     "seconds" : 12,
     "time-of-day" : " 3:28PM",
     "uptime" : 10332,
     "uptime-human" : "  2:52,",
     "user-table" : {
        "user-entry" : [
           {
              "command" : "w --libxo json",
              "from" : "tmux(2948).%0",
              "login-time" : "12:37PM",
              "tty" : "pts/2",
              "user" : "root"
           }
        ]
     },
     "users" : 3
  }
}