5 ms·

Ok, let's take the points one by one. XPath: JSON doesn't need this in, say, Python or Javascript. You write normal code once it's a Python/JS dict/array/list

Ok, let's take the points one by one. XPath: JSON doesn't need this in, say, Python or Javascript. You write normal code once it's a Python/JS dict/array/list and you're done. I don't need yet another language, I have general purpose ones that will do just fine. Attributes and namespaces: these can sort of be faked, but fair enough. But then you get discussions on what should be an attribute and what shouldn't... Schema: pretty sure this exists for JSON XSL: Ah, the poor man's Lisp macros... And, again, easier to do in code in a scripting language.

krick 11y ago
> XPath: JSON doesn't need this in, say, Python or Javascript That's not exactly true. There are books in the library. Here's how I get some book's main character's name: library[5]['mainCharacters'][3]['name']. Except I want to know all main character names in all books. This is a clear, simple request, there's no need for me to put 2 cycles here if I don't have to. So I would end implementing my own XPath here anyway, to write declarative stuff declaratively. But then again, I don't have to, because JsonPath already exists and is just fine.
- kaoD 11y ago
  IMHO JSONPath is an unnecessary DSL when you have a sufficiently powerful and expressive language. It basically abstracts a less-powerful version of the essential higher-order functions. E.g.: > Here's how I get some book's main character's name: library[5]['mainCharacters'][3]['name']. Except I want to know all main character names in all books. library.flatMap(x => x.mainCharacters).map(x => x.name); > This is a clear, simple request, there's no need for me to put 2 cycles here if I don't have to. Using higher-order functions (and a functional programming style) it's still declarative. Yes, there are still nested cycles but, just like in JSONPath, they're hidden in the abstraction. Plus, not using a DSL but a fully-fledged programming/scripting language, you can store intermediate results, make more complex queries, etc. which is more often than not what you need. __ I've used JSONPath mostly in Bash scripts to quickly hack some JSON manipulation, but I'm slowly transitioning into using more powerful scripting languages and not using it anymore. I'm not really that familiar with JSONPath though. Are there any use cases where it's really convenient?
  - krick 11y ago
    I would say, that being a DSL is a benefit by itself. This is how the above example would look in Python: [character['name'] for book in library for character in book['mainCharacters']] (Python also has maps and stuff, but it's considered non-idiomatic, plus flatten would be more awkward.) First of all, syntax is quite different from what you use (Scala, I suppose?), when were we using JSONPath we could just copy 1 line from one project to another and that would be fine. Moreover, both our implementations have the same problems: we assume every book has mainCharacters and every character has name. Would it be JSONPath — it doesn't matter, no 'mainCharacters' means path doesn't match the pattern, just skip it. In our cases this means exceptions. And what if we want to get all 'name' fields from whatever object at whatever depth? Or 'name' of every object where 'color' is 'yellow'? Now, if you consider dictionary structure much more nested (say, some AST) — processing that without errors would be quite painful. And you also would end up writing your own XPath (JSONPath), even with all your map's and reduce's. Of course, should it get complicated enough we would end up needing to write something custom anyway, but stuff like JSONPath just helps to keep things simple when possible. That's it.
- LyndsySimon 11y ago
  > I want to know all main character names in all books Off the top of my head, without testing it: [ character['name'] for characters in [ book['mainCharacters'] for book in library ] for character in characters ]

krick 11y ago

> XPath: JSON doesn't need this in, say, Python or Javascript That's not exactly true. There are books in the library. Here's how I get some book's main character's name: library[5]['mainCharacters'][3]['name']. Except I want to know all main character names in all books. This is a clear, simple request, there's no need for me to put 2 cycles here if I don't have to. So I would end implementing my own XPath here anyway, to write declarative stuff declaratively. But then again, I don't have to, because JsonPath already exists and is just fine.

kaoD 11y ago
IMHO JSONPath is an unnecessary DSL when you have a sufficiently powerful and expressive language. It basically abstracts a less-powerful version of the essential higher-order functions. E.g.: > Here's how I get some book's main character's name: library[5]['mainCharacters'][3]['name']. Except I want to know all main character names in all books. library.flatMap(x => x.mainCharacters).map(x => x.name); > This is a clear, simple request, there's no need for me to put 2 cycles here if I don't have to. Using higher-order functions (and a functional programming style) it's still declarative. Yes, there are still nested cycles but, just like in JSONPath, they're hidden in the abstraction. Plus, not using a DSL but a fully-fledged programming/scripting language, you can store intermediate results, make more complex queries, etc. which is more often than not what you need. __ I've used JSONPath mostly in Bash scripts to quickly hack some JSON manipulation, but I'm slowly transitioning into using more powerful scripting languages and not using it anymore. I'm not really that familiar with JSONPath though. Are there any use cases where it's really convenient?
- krick 11y ago
  I would say, that being a DSL is a benefit by itself. This is how the above example would look in Python: [character['name'] for book in library for character in book['mainCharacters']] (Python also has maps and stuff, but it's considered non-idiomatic, plus flatten would be more awkward.) First of all, syntax is quite different from what you use (Scala, I suppose?), when were we using JSONPath we could just copy 1 line from one project to another and that would be fine. Moreover, both our implementations have the same problems: we assume every book has mainCharacters and every character has name. Would it be JSONPath — it doesn't matter, no 'mainCharacters' means path doesn't match the pattern, just skip it. In our cases this means exceptions. And what if we want to get all 'name' fields from whatever object at whatever depth? Or 'name' of every object where 'color' is 'yellow'? Now, if you consider dictionary structure much more nested (say, some AST) — processing that without errors would be quite painful. And you also would end up writing your own XPath (JSONPath), even with all your map's and reduce's. Of course, should it get complicated enough we would end up needing to write something custom anyway, but stuff like JSONPath just helps to keep things simple when possible. That's it.
LyndsySimon 11y ago
> I want to know all main character names in all books Off the top of my head, without testing it: [ character['name'] for characters in [ book['mainCharacters'] for book in library ] for character in characters ]