4 ms·

JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grow

JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grows around a particular technology.

HdS84 3y ago
Yeah, culture is a big one. See dotnet vs java. The latter picked up many of c# feature over the years but is still much more verbose, e.g. because their developers still abhor var
- brabel 3y ago
  Hey, I work with Java, at work no one has ever complained about a var. Must be your inner circle only?
  - HdS84 3y ago
    Quite possibly. We would need to look through a few OSs projects to determine what's a common style.
crabbone 3y ago
There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far from simple in that later case. I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break, but working around JSONs bad decisions when it comes to number serialization or sequence serialization will probably take days in the best case, with a side-effect that this work will most likely have to be done on an existing product after a customer complained about corrupting or losing their data...
- geysersam 3y ago
  I don't understand the problem you're describing. When would using JSON lead to data loss/corruption?
  - bryanrasmussen 3y ago
    if you are making JSON data to use in your language and application you will probably not have any problem. But as in any thing there can interoperability issues between implementations and programming languages - especially if your JSON is being generated and consumed by your JavaScript site some potential issues https://bishopfox.com/blog/json-interoperability-vulnerabilities https://bishopfox.com/blog/json-interoperability-vulnerabili... on edit: not parent commenter of course, just what I think they might have meant.
    - geysersam 3y ago
      That's very interesting! Thanks for the link.
  - crabbone 3y ago
    Here's a thing that happened in the wild. Neo4j database encodes ids of stored entities as 128-bit integers and it has a JSON interface. When queried from Python, the Python client interprets digit sequences longer than what could possibly fit into 2^32 as floats (even though the native kind of integer in Python is of arbitrary size). So, for a while there weren't too many objects, ids appeared to be all different... until they weren't. It's easy to see how this led to data corruption, I suppose? --- Here's a hypothetical example: few people are aware that JSON allows key duplication in "hash-tables", also, even if they consider such a possibility they might not know that JSON doesn't prescribe which key should win, should there be many of them. They might assume that the definition requires that the first chronologically wins, or last, or... maybe some other rule, but they hope that it's going to be consistent across implementations. Obviously, to screw with developers, JSON doesn't define this. So, it's possible that two different parsers will parse the same JSON with the same fields differently. Where this could theoretically explode? -- Well, some sort of authentication which sends password with other data that can be added by user, and the user intentionally or accidentally adds a "password" field, which may or may not later be overriden and may or may not later be interpreted on the other end as an actual password. --- There are many other things, like, for example, JSON has too many of the "false" values. When different languages generate JSON they may interpret things like "missing key" and "key with the value null" as the same thing or as a different thing. Similarly, for some "false" and "null" are the same thing, while for others it's not.
jillesvangurp 3y ago
Neither did XML originally. XML schema was sort of bolted on via some conventions of defining a schema in the root element. The XML 1.0 spec doesn't mention those. XML Schema is a separate standard that came later. Likewise namespaces are a separate specification as well and not part of the XML specification. The XML specification does have Document Type Definitions (DTD), which were sort of inherited from SGML. This is an optional declaration with its own syntax that defines a DTD. I don't think they were that widely used. XMl Schema started out as an attempt to redefine those in XML. The nice thing with XML Schema was that you could usually ignore them and just use them as documentation of stuff that you might find in a document. Typically, schema urls wouldn't even resolve and throw a 404 instead. More often than not actually. My go-to tool was xpath in those days. Just ignore the schema and cherry pick what comes back using xpath. Usually not that hard. The culture around Json is that it emerged out of dynamic language communities (Javascript, Ruby, Python, etc.) with a long tradition of not annotating things with types and a natural aversion against using schemas when they are not needed. Also, they had the benefit of hindsight and weren't looking to rebuild the web services specs on top of json but were actively trying to get away from that.
- fauigerzigerk 3y ago
  >XML schema was sort of bolted on via some conventions of defining a schema in the root element. I know, and I'm not talking about XML Schema at all (partly because it hurts my brain to even mention the absolute worst specification ever written). I mean just the complexity of the XML data model itself, including namespaces, entity references and the ridiculously convoluted URI spec. That's more than enough to make XML far more complex than JSON. To be fair, XML solves problems that JSON doesn't solve. JSON is not a better XML. JSON's creators simply decided that many of problems that XML solves don't need solving or should not be solved by a data format specification.
- euroderf 3y ago
  I like DTDs. For all their weirdness, they solve a problem rather simply. Reminiscent of BNF. (Altho admittedly they are clueless about namespaces and other fancy bolt-ons.)

JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grows around a particular technology.

HdS84 3y ago

Yeah, culture is a big one. See dotnet vs java. The latter picked up many of c# feature over the years but is still much more verbose, e.g. because their developers still abhor var

brabel 3y ago
Hey, I work with Java, at work no one has ever complained about a var. Must be your inner circle only?
- HdS84 3y ago
  Quite possibly. We would need to look through a few OSs projects to determine what's a common style.

crabbone 3y ago

There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far from simple in that later case. I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break, but working around JSONs bad decisions when it comes to number serialization or sequence serialization will probably take days in the best case, with a side-effect that this work will most likely have to be done on an existing product after a customer complained about corrupting or losing their data...

geysersam 3y ago
I don't understand the problem you're describing. When would using JSON lead to data loss/corruption?
- bryanrasmussen 3y ago
  if you are making JSON data to use in your language and application you will probably not have any problem. But as in any thing there can interoperability issues between implementations and programming languages - especially if your JSON is being generated and consumed by your JavaScript site some potential issues https://bishopfox.com/blog/json-interoperability-vulnerabilities https://bishopfox.com/blog/json-interoperability-vulnerabili... on edit: not parent commenter of course, just what I think they might have meant.
  - geysersam 3y ago
    That's very interesting! Thanks for the link.
- crabbone 3y ago
  Here's a thing that happened in the wild. Neo4j database encodes ids of stored entities as 128-bit integers and it has a JSON interface. When queried from Python, the Python client interprets digit sequences longer than what could possibly fit into 2^32 as floats (even though the native kind of integer in Python is of arbitrary size). So, for a while there weren't too many objects, ids appeared to be all different... until they weren't. It's easy to see how this led to data corruption, I suppose? --- Here's a hypothetical example: few people are aware that JSON allows key duplication in "hash-tables", also, even if they consider such a possibility they might not know that JSON doesn't prescribe which key should win, should there be many of them. They might assume that the definition requires that the first chronologically wins, or last, or... maybe some other rule, but they hope that it's going to be consistent across implementations. Obviously, to screw with developers, JSON doesn't define this. So, it's possible that two different parsers will parse the same JSON with the same fields differently. Where this could theoretically explode? -- Well, some sort of authentication which sends password with other data that can be added by user, and the user intentionally or accidentally adds a "password" field, which may or may not later be overriden and may or may not later be interpreted on the other end as an actual password. --- There are many other things, like, for example, JSON has too many of the "false" values. When different languages generate JSON they may interpret things like "missing key" and "key with the value null" as the same thing or as a different thing. Similarly, for some "false" and "null" are the same thing, while for others it's not.

jillesvangurp 3y ago

Neither did XML originally. XML schema was sort of bolted on via some conventions of defining a schema in the root element. The XML 1.0 spec doesn't mention those. XML Schema is a separate standard that came later. Likewise namespaces are a separate specification as well and not part of the XML specification. The XML specification does have Document Type Definitions (DTD), which were sort of inherited from SGML. This is an optional declaration with its own syntax that defines a DTD. I don't think they were that widely used. XMl Schema started out as an attempt to redefine those in XML. The nice thing with XML Schema was that you could usually ignore them and just use them as documentation of stuff that you might find in a document. Typically, schema urls wouldn't even resolve and throw a 404 instead. More often than not actually. My go-to tool was xpath in those days. Just ignore the schema and cherry pick what comes back using xpath. Usually not that hard. The culture around Json is that it emerged out of dynamic language communities (Javascript, Ruby, Python, etc.) with a long tradition of not annotating things with types and a natural aversion against using schemas when they are not needed. Also, they had the benefit of hindsight and weren't looking to rebuild the web services specs on top of json but were actively trying to get away from that.

fauigerzigerk 3y ago
>XML schema was sort of bolted on via some conventions of defining a schema in the root element. I know, and I'm not talking about XML Schema at all (partly because it hurts my brain to even mention the absolute worst specification ever written). I mean just the complexity of the XML data model itself, including namespaces, entity references and the ridiculously convoluted URI spec. That's more than enough to make XML far more complex than JSON. To be fair, XML solves problems that JSON doesn't solve. JSON is not a better XML. JSON's creators simply decided that many of problems that XML solves don't need solving or should not be solved by a data format specification.
euroderf 3y ago
I like DTDs. For all their weirdness, they solve a problem rather simply. Reminiscent of BNF. (Altho admittedly they are clueless about namespaces and other fancy bolt-ons.)