4 ms·

Isn't every programming language a json query language? Particularly functional ones?

capableweb 5y ago
I can only think of one language that supports JSON "natively": JavaScript. For the rest of the languages, you usually need a parser (which, to be fair, JavaScript also needs, it just happens to come with the environment you use (browsers/NodeJS)) before you can actually do anything with the data.
- johnbeech 5y ago
  Agreed, I generally impress colleagues with how fast it is to solve problems with JSON / JS - the big advantage for me is being able to "dump" a portion of program memory to JSON, and then reload that into state of the application. It makes systems much easier to understand when you can peer inside the memory structures. I find by comparison that strongly typed languages end up with a huge amount of boiler plate and abstractions, you start to question which bits/bytes actually matter. JSON reduces a problem space to something meaningful and easily craftable by humans.
- jbverschoor 5y ago
  You can eval() json.. That's where it came from
  - michaelmior 5y ago
    You can in JavaScript but you almost certainly don't want to when you can just use JSON.parse and avoid the possibility of the execution of arbitrary code.
    - jbverschoor 5y ago
      I'm not saying it's a good idea. Javascript itself has many bad ideas. I'm just saying that's where it all started.
dusted 5y ago
I'd say yes, even the node repl is pretty comfortable for working with json, but I know it's popular to hate on js for not being typescript.
gregwebs 5y ago
Sure, just like you don’t have to use SQL. JSONiq is strongly typed, so only the strongly typed languages are equivalent. The point of this project, like SQL, is to have something programming language agnostic that can be understood and optimized by a db or a tool that doesn’t use your programming language. It’s mostly designed for data analysis and data interchange.
emmanueloga_ 5y ago
This answer will be a bit convoluted but hopefully has some interesting and related concepts ... First, from [1]: ... two representative [JSON] transformation tasks are considered ... The exercise demonstrates that the absence of parent or ancestor axes in the native representation of JSON means that the transformation task needs to be approached in a very different way. The article shows that the ability to "navigate upward" to the parent of a node can make certain queries and transformation easier to implement. BTW, as far as I can tell, JSONIq does not provide a way to "navigate upward" ... But! also from [1]: The ability to navigate upwards (and to a lesser extent, sideways, to preceding and following siblings) clearly has advantages and disadvantages. Without upwards navigation, a transformation process that operates primarily as a recursive tree walk cannot discover the context of leaf nodes (for example, when processing a price, what product does it relate to?), so this information needs to be passed down in the form of parameters. However, the convenience of being able to determine the context of a node comes at a significant price. I remember dealing with trees in pure functional languages and finding that typically implementing parent pointers can be tricky [2]. I think if we combine this two facts, we can see that not all languages make the same query or transformation tasks equally easy. 1: Page 167 of https://archive.xmlprague.cz/2016/files/xmlprague-2016-proceedings.pdf https://archive.xmlprague.cz/2016/files/xmlprague-2016-proce... 2: https://okmij.org/ftp/Scheme/xml.html#parent-ptr https://okmij.org/ftp/Scheme/xml.html#parent-ptr

I can only think of one language that supports JSON "natively": JavaScript. For the rest of the languages, you usually need a parser (which, to be fair, JavaScript also needs, it just happens to come with the environment you use (browsers/NodeJS)) before you can actually do anything with the data.

johnbeech 5y ago
Agreed, I generally impress colleagues with how fast it is to solve problems with JSON / JS - the big advantage for me is being able to "dump" a portion of program memory to JSON, and then reload that into state of the application. It makes systems much easier to understand when you can peer inside the memory structures. I find by comparison that strongly typed languages end up with a huge amount of boiler plate and abstractions, you start to question which bits/bytes actually matter. JSON reduces a problem space to something meaningful and easily craftable by humans.
jbverschoor 5y ago
You can eval() json.. That's where it came from
- michaelmior 5y ago
  You can in JavaScript but you almost certainly don't want to when you can just use JSON.parse and avoid the possibility of the execution of arbitrary code.
  - jbverschoor 5y ago
    I'm not saying it's a good idea. Javascript itself has many bad ideas. I'm just saying that's where it all started.

dusted 5y ago

I'd say yes, even the node repl is pretty comfortable for working with json, but I know it's popular to hate on js for not being typescript.

gregwebs 5y ago

Sure, just like you don’t have to use SQL. JSONiq is strongly typed, so only the strongly typed languages are equivalent. The point of this project, like SQL, is to have something programming language agnostic that can be understood and optimized by a db or a tool that doesn’t use your programming language. It’s mostly designed for data analysis and data interchange.

emmanueloga_ 5y ago

This answer will be a bit convoluted but hopefully has some interesting and related concepts ... First, from [1]: ... two representative [JSON] transformation tasks are considered ... The exercise demonstrates that the absence of parent or ancestor axes in the native representation of JSON means that the transformation task needs to be approached in a very different way. The article shows that the ability to "navigate upward" to the parent of a node can make certain queries and transformation easier to implement. BTW, as far as I can tell, JSONIq does not provide a way to "navigate upward" ... But! also from [1]: The ability to navigate upwards (and to a lesser extent, sideways, to preceding and following siblings) clearly has advantages and disadvantages. Without upwards navigation, a transformation process that operates primarily as a recursive tree walk cannot discover the context of leaf nodes (for example, when processing a price, what product does it relate to?), so this information needs to be passed down in the form of parameters. However, the convenience of being able to determine the context of a node comes at a significant price. I remember dealing with trees in pure functional languages and finding that typically implementing parent pointers can be tricky [2]. I think if we combine this two facts, we can see that not all languages make the same query or transformation tasks equally easy. 1: Page 167 of https://archive.xmlprague.cz/2016/files/xmlprague-2016-proceedings.pdf https://archive.xmlprague.cz/2016/files/xmlprague-2016-proce... 2: https://okmij.org/ftp/Scheme/xml.html#parent-ptr https://okmij.org/ftp/Scheme/xml.html#parent-ptr