[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Light weight support for JSON
From: |
Lawrence Velázquez |
Subject: |
Re: Light weight support for JSON |
Date: |
Sun, 28 Aug 2022 14:44:21 -0400 |
User-agent: |
Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a |
On Sun, Aug 28, 2022, at 2:29 PM, Yair Lenga wrote:
> I do not think that JSON (and REST) are "data exchange format of the
> month". Those are established formats that are here to stay. Like YAML.
> Those are "cornerstones" of cloud computing/configuration. I do not have to
> argue for them, they can speak for themselves.
You *do* have to argue why a shell should provide first-class support
for them, or for any concrete data format. Shells exist on a much
longer time scale than anything you've been talking about and are
used in essentially every conceivable computing context. "I think
JSON is *extra-special* important though" is not a reason why the
shell itself should give it special attention.
> As for using external utilities: two main issues:
> * Performance - Processing data in bash processes can be 100X times faster
> than using external tools. The fork/exec is expensive.
And? Are you running jq 100,000 times in a tight loop?
> * Readability - Each tool has its own syntax, escapes, etc. The final
> result of mixing JQ and bash is not pretty (just lookup jq/bash questions
> on stack overflow)
Neither is your example. Bash's "type system" (as it were) cannot
fully represent all JSON objects, so you're going to end up with
some sort of gross approximation regardless.
> Having them as a loadable extension seems like a good practical solution.
> They do not have to be "built-in".
The "csv" loadable provides some precedent for this. It won't solve
the representation problem, though.
--
vq
Re: Light weight support for JSON, Dale R. Worley, 2022/08/28
Re: Light weight support for JSON, Chet Ramey, 2022/08/29
Re: Light weight support for JSON, Chet Ramey, 2022/08/29