Jid – Drill down JSON data incrementally • Hacker News Board

Re: Jid – Drill down JSON data incrementally

#21

Post by gwu78 » Sun, Dec 04, 2016, 12:54 AM UTC

asimjalis wrote: post #6

How can I use wildcards in queries? For example consider this. echo '{"users":[{"name":"s1","id":1},{"name":"s2","id":2}]}'|jid I can query users[0].id or users[1].id. How can I get all the ids? I tried users[*].id which didn’t work. In Clojure I use specter [1] for this which is able to handle wildcards using ALL. [1] https://github.com/nathanmarz/specter

echo '{"users":[{"name":"s1","id":1},{"name":"s2","id":2}]}' |exec tr '{' '\12'|exec sed '/name/!d;s/\"//g;s/}.*//'

output:

   name:s1,id:1
   name:s2,id:2

Re: Jid – Drill down JSON data incrementally

#22

Post by mypalmike » Sun, Dec 04, 2016, 1:24 AM UTC

I built a similar thing recently with python. Not complete, but a bunch of stuff does work. It's modeled on interacting on-device with a JunOS or Cisco config. Probably the most interesting feature is text completion.

https://github.com/mypalmike/ijsoned

Re: Jid – Drill down JSON data incrementally

#23

Post by vikiomega9 » Sun, Dec 04, 2016, 1:27 AM UTC

cle wrote: post #18

fiatjaf wrote: post #8

Earlier quoted context omitted.

Do you think that is bad? Many people like LISP.

I think Lisp folks complain because so much effort has been spent to converge on the same stuff we already had. When it comes to data serialization, over many decades we've invented many formats, and they usually go off on tangents and then converge on essentially the same stuff. Lispers respond: "We told you so."

Can you point me to an example of a serialization that was reinvented?

Re: Jid – Drill down JSON data incrementally

#24

Post by mypalmike » Sun, Dec 04, 2016, 1:47 AM UTC

Animats wrote: post #5

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()". Yesterday, state machine programming in JSON. Today, an inspector.

If LISP had a widely-accepted standard, non-turing-complete subset to represent the equivalent persisted data structures JSON does, it would still be less readable than JSON.

There are reasons JSON is the lingua franca of modern API interaction and LISP is not.

Re: Jid – Drill down JSON data incrementally

#25

Post by andrewstuart2 » Sun, Dec 04, 2016, 1:53 AM UTC

Animats wrote: post #5

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()". Yesterday, state machine programming in JSON. Today, an inspector.

This is a fairly common occurrence for any declarative data serialization format. Just look at all the crappy imperative XML programs you can write in ant. And plenty of other imperative XML "languages."

Re: Jid – Drill down JSON data incrementally

#26

Post by showkhill » Sun, Dec 04, 2016, 2:28 AM UTC

J-drilla

Re: Jid – Drill down JSON data incrementally

#27

Post by adzm » Sun, Dec 04, 2016, 3:20 AM UTC

vikiomega9 wrote: post #23

cle wrote: post #18

Earlier quoted context omitted.

I think Lisp folks complain because so much effort has been spent to converge on the same stuff we already had. When it comes to data serialization, over many decades we've invented many formats, and they usually go off on tangents and then converge on essentially the same stuff. Lispers respond: "We told you so."

Can you point me to an example of a serialization that was reinvented?

JSON vs S-expressions

Re: Jid – Drill down JSON data incrementally

#28

Post by Spivak » Sun, Dec 04, 2016, 3:37 AM UTC

mypalmike wrote: post #24

Animats wrote: post #5

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()". Yesterday, state machine programming in JSON. Today, an inspector.

If LISP had a widely-accepted standard, non-turing-complete subset to represent the equivalent persisted data structures JSON does, it would still be less readable than JSON. There are reasons JSON is the lingua franca of modern API interaction and LISP is not.

Whatever example I give you're just going to complain that it's not widely accepted because it's not JSON/YAML/XML. Since just about every scripting language uses similar syntax to JSON there's an argument to be made that familiarity is the most important characteristic. However, that doesn't mean that LISP is unfit for the job from a technical perspective. If we're going to start evaluating JSON as code then there's a strong argument to be made that a LISP is better suited since that's one of its core principles and is already well developed.

    '(
      (first-name john)
      (last-name smith)
      (age 23)
      (parents jane jim)
    )

    {
      "first name": "john",
      "last name": "smith",
      "age": 23,
      "parents": ["jim", "jane"]
    }

Re: Jid – Drill down JSON data incrementally

#29

Post by voltagex_ » Sun, Dec 04, 2016, 4:26 AM UTC

hyperpallium wrote: post #20

dorianm wrote: post #15

Earlier quoted context omitted.

How would you do a `data.keys.sort` with jq? Here I don't have to learn a new programming language or hack around with UNIX pipes ;)

jq has sort and sort_by(exp). Its | is a jq operator, not a unix pipe. It's true it's a new lang, and although simple, I often have to look things up. It might be nice to have a jq REPL, so needn't quote, and easier to keep state around.

I find jq syntax tricky, and it's difficult to work out what I need to get to specific elements. I guess I'm more used to things like XPath. Seconding the request for a REPL

Re: Jid – Drill down JSON data incrementally

#30

Post by falcolas » Sun, Dec 04, 2016, 4:33 AM UTC

Spivak wrote: post #28

mypalmike wrote: post #24

Earlier quoted context omitted.

If LISP had a widely-accepted standard, non-turing-complete subset to represent the equivalent persisted data structures JSON does, it would still be less readable than JSON. There are reasons JSON is the lingua franca of modern API interaction and LISP is not.

Whatever example I give you're just going to complain that it's not widely accepted because it's not JSON/YAML/XML. Since just about every scripting language uses similar syntax to JSON there's an argument to be made that familiarity is the most important characteristic. However, that doesn't mean that LISP is unfit for the job from a technical perspective. If we're going to start evaluating JSON as code then there's…

Might change that a bit to more accurately represent the same type of objects described in your JSON.

    '(
      (first-name "john")
      (last-name "smith")
      (age 23)
      (parents ("jane" "jim"))
    )

Of course, for a pure set of such simply formatted data (hashes, lists, strings, numbers), you could use almost any data serialization format. S-Exs don't really offer anything special here that can't also be done in XML, MessagePack, SQL, protobuff, bencode, thrift, or any of a dozen other serialization formats.

Then again, JSON doesn't really bring much special to the table in this case either (other than having an encoder built into most Javascript intrepreters).