7 ms·

Why would you need any of that? A date type is bloat, store an epoch number. Comments have no place in a data format. Append is exactly the same as with XML: Yo

by onli 10y ago

Why would you need any of that? A date type is bloat, store an epoch number. Comments have no place in a data format. Append is exactly the same as with XML: You take the part you want and add it at the right place in a list of the other file. I'd argue the lack of namespaces makes it easier than with XML. For the binary data: JSON is not a binary format, one should not try to mix those. To encode it and store it as a string is exactly right. Otherwise a database as blob store is the better place for that.

maxxxxx 10y ago
Comments are important ina format that's being used for configuration as JSON is. Commenting out things makes for easier revert if something doesn't work. Having a Line of comment in front of each setting is also a good thing. This is just basic practicality. You can't easily append something to an already existing JSON file. You have to decode the whole thing first and then write it back whole. XML has the same problem. That's why I said we replaced one bad format with another. JSON is not an improvement over XML. It replaced one set of weaknesses with another.
- IgorPartola 10y ago
  Maybe we shouldn't use JSON as a configuration format. There are numerous better alternatives such as INI files and YAML.
  - maxxxxx 10y ago
    I personally use INI files quit a bit but the cool kids insist on JSON.
    - dvirsky 10y ago
      TOML seems like a nice middle ground, it's gaining some popularity in the Go world.
      - merb 10y ago
        or HOCON which is often used in Scala ;)
  - vram22 10y ago
    INI files are cool, IMO [1]. Though they may have originated in Windows or DOS, other tech uses them too nowadays (and from long, of course). Some languages must have support for INI files in their standard or 3rd-party libraries. I know Python does, in the ConfigParser module. In fact, I'm currently using it in a project I'm working on for a client. [1] I think they are cool because of their simplicity - it is just a two-level hierarchy - sections and options within sections. And options are key-value pairs. For many applications, this is enough, and any format that supports more may be overkill (though would still work). Edited to add the [1] footnote.
- davexunit 10y ago
  JSON is not for people to write, despite what people try to do. It's for machines.
  - pg314 10y ago
    From [1]: "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write." [1] http://www.json.org/ http://www.json.org/
    - davexunit 10y ago
      It may say that, but it's main use is a serialization format for machines. The lack of comments makes it apparent that it is not for people. When you want comments, what you actually want to do is write code in a real programming language.
      - matt4077 10y ago
        Or, maybe, our tools should evolve with an eye on how they are actually being used. JSON/YAML/TOML/INI are all intended to store arbitrary data structures, and are all required to be written and read by algorithms. It doesn't make sense to split that world into "these are usually created/consumed only by software" and "these are for humans".
        maxxxxx 10y ago
        This whole thing is just a variation of the "you aren't doing it right" syndrome. Be it Scrum, OO, FP, XML, JSON, whenever you criticize one of them people will tell you "this is not what it was intended for" even though a lot of people use it that way.
        Spivak 10y ago
        But the more valid form of this argument is "not the right tool for the job". Trying to be all encompassing is how we wound up with XML.
- vinceguidry 10y ago
  I'd much rather deal with JSON than XML. XML is a document format, JSON is a data format. You extract data out of documents. JSON is 10 times easier to traverse than XML. XML is so difficult to traverse that you have to use a special language to do it cleanly, XPath. JSON, you just read it into whatever hash map data type your language has built-in and use your standard library.
  - jimbokun 10y ago
    "XML is a document format" And works very well as a document format, and JSON works very poorly as a document format! So if you have documents (a novel, an article, a manual, etc.), XML is still a very nice choice. But was a mistake to use XML as a data format. (Just elaborating on your point.)
    - maxxxxx 10y ago
      How do you know that you are dealing with a document or data? Isn't a document just data too?
      - vram22 10y ago
        I'm not an expert on the difference, but informally, I'd say that the difference is this: a "document" will have more and/or larger passages of text, and the fields are mainly meant as metadata to add meaning to it. A good example would be a real document like a book - when stored in an XML file, a lot of the content would be the text of the book, and you would have some XML elements like <book>, <chapter>, <section>, <TOC>, etc. But for "data", a good example would be an invoice or a purchase order or a part record - while they do have text, it will be mainly in the form of structured fields (typically not too long, unlike a chapter or section in a book), which can again be stored in XML elements. And this is where the siblings and others are arguing about - which (XML or JSON) is a better format for what type - document or data.
      - jimbokun 10y ago
        "(a novel, an article, a manual, etc.)" So something meant to be read by humans. XML is nice for marking up the actual text with structure like chapters, sections, footnotes, references, formatting, etc. (thus, the ML in XML comes from "markup language") With JSON, there isn't really a notion of prose text to "mark up". It is structured data meant to be processed by machines. (Of course it is useful for humans to read and write JSON sometimes, but JSON is primarily meant to be input to or output from some computing process. You wouldn't sit down to read a JSON doucment unless you are some super weird programmer dude.)
- badthingfactory 10y ago
  The mistake here is using JSON for configuration.
- always_good 10y ago
  The creator of JSON is right: without comments, people won't be tempted to encode directives in comments like we have with XML. Want comments? Pipe through json5. Still vastly simpler than XML. It's hard to take people's criticism seriously every time JSON comes up. There's a sibling comment that even suggests that it's a mistake to use JSON for config in the first place. C'mon.
azeirah 10y ago
Comments do have a place in a data format if the format is intended to be human readable.
- natch 10y ago
  I think JSON is intended to strike the right balance between readability by machines (primary goal) and readability by humans (secondary). Comments don't make sense to the machine and are just overhead. And they tend to be abused or extended in hacky ways. So I'm glad they're not there.
- Klathmon 10y ago
  To expand on what the other commenter said. The creator of JSON was explicitly against comments for a few reasons. The biggest one was that comments are often used to "extend" a format. Look at doc-block, annotations, etc... In order for the format to work, everyone had to use the exact same set of rules, and that meant that if people started adding their own "crap" to the format in a "backwards compatible" way you'd lose what makes it special. So he didn't add comments. And I personally think it worked out.
  - azeirah 10y ago
    Ah ok, I hadn't considered that, that's quite clever really.
  - dv_dt 10y ago
    So now lots of JSON parsers have extensions to ignore comment extensions to the format...
  - legutierr 10y ago
    This argument against the inclusion of comments is a good argument in favor of the inclusion of a date data type and a binary data type. Right now, there are a number of different ways to encode both types of data, and you see them all in the wild. And extra custom serialization and deserialization steps are always required to handle them.
jimbokun 10y ago
"Otherwise a database as blob store is the better place for that." Actually, I was thinking something more like Protocol Buffers or Avro if you are looking for a binary format for transmitting structured data.
- onli 10y ago
  Sure, both seem better for that. At that moment I was thinking only of storage, not transmitting.
- vram22 10y ago
  Coincidentally I was looking at MessagePack recently. It seems to have some interesting features. Not done a proper study of it vs. other competing or comparable formats, though.
derefr 10y ago
> A date type is bloat, store an epoch number. Unix timestamps are lossy. 1. No time zones: you can't recover the sender's time-zone from it. (Not the end of the world, obviously.) 2. No defined calendar: if you convert an arbitrary datetime into a timestamp, you don't actually have enough information to convert it back into a datetime, because the same instant of continuous time has different representations in different calendars. 3. The unix epoch is very recent, and there is no such thing as a "negative timestamp": you can't convert historical datetimes to timestamps. If you're trying to pass around e.g. medical records tagged with their dates, what do you do with the ones about things that happened before 1970? (And without problem 3, problem 2 would be even worse: you'd have to care about calendars beyond the Julian and Gregorian ones, to represent those historical dates. Some calendars don't map monotonically to continuous time! Some instants have multiple representations in the same calendar! Some instants have no representation in a given calendar!) But the worst problem of all, that affects you even if you don't care about encoding weird historical dates: 4. Timestamps don't "care about" leap-seconds [i.e. the standard doesn't force timestamps to either include or exclude them.] Therefore, every time there's a leap second, Unix time becomes less precise by one second (the integer representing a timestamp after a leap second could map to dt n, or dt n-1, depending on if [and exactly when!] the system that generated it adjusted its clock for the leap-second.) That means that right now, if an unknown system handed you a timestamp that purportedly represents the current time, you'd not actually be able to know that with less than a ±27 second error-bar. That number will only keep climbing. > to encode it and store it as a string is exactly right. That's not actually the problem. It'd be fine if JSON took binary data and then represented it in some human-readable encoding like Base64. The problem is that JSON doesn't specify the representation of binary data, or the mapping between binary data and such a representation. So you can't take a binary buffer, drop it into a JSON serializer, and expect it to pop out the other side on any random JSON-speaking system as a binary buffer. Instead, both sides have to have known characteristics (an agreement to represent binaries in JSON a certain way.) The whole point of a serialization format is to bundle up those guaranteed characteristics, so that once you know "this system speaks JSON", you don't have to ask any more questions. JSON fails at being a serialization format because you still have to ask the other side how it "expects to see" binaries represented, or dates represented.
- 10y ago

by onli 10y ago

maxxxxx 10y ago

Comments are important ina format that's being used for configuration as JSON is. Commenting out things makes for easier revert if something doesn't work. Having a Line of comment in front of each setting is also a good thing. This is just basic practicality. You can't easily append something to an already existing JSON file. You have to decode the whole thing first and then write it back whole. XML has the same problem. That's why I said we replaced one bad format with another. JSON is not an improvement over XML. It replaced one set of weaknesses with another.

IgorPartola 10y ago
Maybe we shouldn't use JSON as a configuration format. There are numerous better alternatives such as INI files and YAML.
- maxxxxx 10y ago
  I personally use INI files quit a bit but the cool kids insist on JSON.
  - dvirsky 10y ago
    TOML seems like a nice middle ground, it's gaining some popularity in the Go world.
    - merb 10y ago
      or HOCON which is often used in Scala ;)
- vram22 10y ago
  INI files are cool, IMO [1]. Though they may have originated in Windows or DOS, other tech uses them too nowadays (and from long, of course). Some languages must have support for INI files in their standard or 3rd-party libraries. I know Python does, in the ConfigParser module. In fact, I'm currently using it in a project I'm working on for a client. [1] I think they are cool because of their simplicity - it is just a two-level hierarchy - sections and options within sections. And options are key-value pairs. For many applications, this is enough, and any format that supports more may be overkill (though would still work). Edited to add the [1] footnote.
davexunit 10y ago
JSON is not for people to write, despite what people try to do. It's for machines.
- pg314 10y ago
  From [1]: "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write." [1] http://www.json.org/ http://www.json.org/
  - davexunit 10y ago
    It may say that, but it's main use is a serialization format for machines. The lack of comments makes it apparent that it is not for people. When you want comments, what you actually want to do is write code in a real programming language.
    - matt4077 10y ago
      Or, maybe, our tools should evolve with an eye on how they are actually being used. JSON/YAML/TOML/INI are all intended to store arbitrary data structures, and are all required to be written and read by algorithms. It doesn't make sense to split that world into "these are usually created/consumed only by software" and "these are for humans".
      - maxxxxx 10y ago
        This whole thing is just a variation of the "you aren't doing it right" syndrome. Be it Scrum, OO, FP, XML, JSON, whenever you criticize one of them people will tell you "this is not what it was intended for" even though a lot of people use it that way.
        Spivak 10y ago
        But the more valid form of this argument is "not the right tool for the job". Trying to be all encompassing is how we wound up with XML.
vinceguidry 10y ago
I'd much rather deal with JSON than XML. XML is a document format, JSON is a data format. You extract data out of documents. JSON is 10 times easier to traverse than XML. XML is so difficult to traverse that you have to use a special language to do it cleanly, XPath. JSON, you just read it into whatever hash map data type your language has built-in and use your standard library.
- jimbokun 10y ago
  "XML is a document format" And works very well as a document format, and JSON works very poorly as a document format! So if you have documents (a novel, an article, a manual, etc.), XML is still a very nice choice. But was a mistake to use XML as a data format. (Just elaborating on your point.)
  - maxxxxx 10y ago
    How do you know that you are dealing with a document or data? Isn't a document just data too?
    - vram22 10y ago
      I'm not an expert on the difference, but informally, I'd say that the difference is this: a "document" will have more and/or larger passages of text, and the fields are mainly meant as metadata to add meaning to it. A good example would be a real document like a book - when stored in an XML file, a lot of the content would be the text of the book, and you would have some XML elements like <book>, <chapter>, <section>, <TOC>, etc. But for "data", a good example would be an invoice or a purchase order or a part record - while they do have text, it will be mainly in the form of structured fields (typically not too long, unlike a chapter or section in a book), which can again be stored in XML elements. And this is where the siblings and others are arguing about - which (XML or JSON) is a better format for what type - document or data.
    - jimbokun 10y ago
      "(a novel, an article, a manual, etc.)" So something meant to be read by humans. XML is nice for marking up the actual text with structure like chapters, sections, footnotes, references, formatting, etc. (thus, the ML in XML comes from "markup language") With JSON, there isn't really a notion of prose text to "mark up". It is structured data meant to be processed by machines. (Of course it is useful for humans to read and write JSON sometimes, but JSON is primarily meant to be input to or output from some computing process. You wouldn't sit down to read a JSON doucment unless you are some super weird programmer dude.)
badthingfactory 10y ago
The mistake here is using JSON for configuration.
always_good 10y ago
The creator of JSON is right: without comments, people won't be tempted to encode directives in comments like we have with XML. Want comments? Pipe through json5. Still vastly simpler than XML. It's hard to take people's criticism seriously every time JSON comes up. There's a sibling comment that even suggests that it's a mistake to use JSON for config in the first place. C'mon.

azeirah 10y ago

Comments do have a place in a data format if the format is intended to be human readable.

natch 10y ago
I think JSON is intended to strike the right balance between readability by machines (primary goal) and readability by humans (secondary). Comments don't make sense to the machine and are just overhead. And they tend to be abused or extended in hacky ways. So I'm glad they're not there.
Klathmon 10y ago
To expand on what the other commenter said. The creator of JSON was explicitly against comments for a few reasons. The biggest one was that comments are often used to "extend" a format. Look at doc-block, annotations, etc... In order for the format to work, everyone had to use the exact same set of rules, and that meant that if people started adding their own "crap" to the format in a "backwards compatible" way you'd lose what makes it special. So he didn't add comments. And I personally think it worked out.
- azeirah 10y ago
  Ah ok, I hadn't considered that, that's quite clever really.
- dv_dt 10y ago
  So now lots of JSON parsers have extensions to ignore comment extensions to the format...
- legutierr 10y ago
  This argument against the inclusion of comments is a good argument in favor of the inclusion of a date data type and a binary data type. Right now, there are a number of different ways to encode both types of data, and you see them all in the wild. And extra custom serialization and deserialization steps are always required to handle them.

jimbokun 10y ago

"Otherwise a database as blob store is the better place for that." Actually, I was thinking something more like Protocol Buffers or Avro if you are looking for a binary format for transmitting structured data.

onli 10y ago
Sure, both seem better for that. At that moment I was thinking only of storage, not transmitting.
vram22 10y ago
Coincidentally I was looking at MessagePack recently. It seems to have some interesting features. Not done a proper study of it vs. other competing or comparable formats, though.

derefr 10y ago

> A date type is bloat, store an epoch number. Unix timestamps are lossy. 1. No time zones: you can't recover the sender's time-zone from it. (Not the end of the world, obviously.) 2. No defined calendar: if you convert an arbitrary datetime into a timestamp, you don't actually have enough information to convert it back into a datetime, because the same instant of continuous time has different representations in different calendars. 3. The unix epoch is very recent, and there is no such thing as a "negative timestamp": you can't convert historical datetimes to timestamps. If you're trying to pass around e.g. medical records tagged with their dates, what do you do with the ones about things that happened before 1970? (And without problem 3, problem 2 would be even worse: you'd have to care about calendars beyond the Julian and Gregorian ones, to represent those historical dates. Some calendars don't map monotonically to continuous time! Some instants have multiple representations in the same calendar! Some instants have no representation in a given calendar!) But the worst problem of all, that affects you even if you don't care about encoding weird historical dates: 4. Timestamps don't "care about" leap-seconds [i.e. the standard doesn't force timestamps to either include or exclude them.] Therefore, every time there's a leap second, Unix time becomes less precise by one second (the integer representing a timestamp after a leap second could map to dt n, or dt n-1, depending on if [and exactly when!] the system that generated it adjusted its clock for the leap-second.) That means that right now, if an unknown system handed you a timestamp that purportedly represents the current time, you'd not actually be able to know that with less than a ±27 second error-bar. That number will only keep climbing. > to encode it and store it as a string is exactly right. That's not actually the problem. It'd be fine if JSON took binary data and then represented it in some human-readable encoding like Base64. The problem is that JSON doesn't specify the representation of binary data, or the mapping between binary data and such a representation. So you can't take a binary buffer, drop it into a JSON serializer, and expect it to pop out the other side on any random JSON-speaking system as a binary buffer. Instead, both sides have to have known characteristics (an agreement to represent binaries in JSON a certain way.) The whole point of a serialization format is to bundle up those guaranteed characteristics, so that once you know "this system speaks JSON", you don't have to ask any more questions. JSON fails at being a serialization format because you still have to ask the other side how it "expects to see" binaries represented, or dates represented.

10y ago