4 ms·

JSON really shouldn't change at all that is why it is so great, basic types and very simple and clean. We should build a fortified defense around JSON and keep

JSON really shouldn't change at all that is why it is so great, basic types and very simple and clean. We should build a fortified defense around JSON and keeping it the same. Of course there is no problem making a new standard, mongo did that with BSON. It is different and should be called different, nothing wrong with abstractions. The reason we all love JSON is that it has stayed the same. Develop a coffescript like JSON precompiler with comments and trailing commas and all sorts of things like no quoted keys if needed but call it something different. I think the last thing anyone wants to do it shake the JSON standard or have to have multiple parsers try for all the new JSON formats/schemas/namespaces/etc like an XML SOAP nightmare. EDIT: Ok so it does have compiling to regular JSON but just not a fan of the name. This file is written in JSON5 syntax, naturally, but npm needs a regular JSON file, so compile via `npm run build`. Be sure to keep both in sync!

stormbrew 13y ago
> Develop a coffescript like JSON precompiler with comments and trailing commas and all sorts of things like no quoted keys if needed but call it something different. Someone did, it's called yaml.
- theg2 13y ago
  And I still don't understand why you'd pick yaml over anything else out there.
  - stormbrew 13y ago
    I pick it for config files humans have to write and read because writing and reading json as a human is tedious and error prone.
    - vertex-four 13y ago
      As someone who has to write yaml... writing yaml is significantly more error-prone than JSON. It has far more edge cases than JSON does.
      - stormbrew 13y ago
        I agree it has a lot of corner cases, but they are mostly in service of allowing for an uncluttered document. The fact that you can always write a subset of the document in json is helpful when things get hairy. But this is a thing that often gets ignored when talking about what humans are good at reading and writing. We aren't computers (or at least, we aren't as linear of computers). It's obvious enough in the languages that we speak and write every day with each other that we derive from and plant a lot of meaning in the margins of our expression. We tend to understand things quite clearly when noise has been elided out. A lot of JSON becomes pure noise: "{{[[{[{{[". Really, though, what I'm most in favour of is that now that we've agreed on a basic data model that is less insane than its obvious predecessors (ASN.1 and XML) it would be nice if applications with configuration opened themselves to allowing the user to decide the specific format for their own benefit. If it's TOML or JSON or JSON5 or JSON+comments (Sublime Text) or YAML or whatever, so long as it results in the same structure who cares?
        TheZenPsycho 13y ago
        > A lot of JSON becomes pure noise: "{{[[{[{{[". I'd rather that be visible brackets than invisible whitespace.
        stormbrew 13y ago
        Why? Assuming 'invisible whitespace' in this context is actually a meaningful thing. I find it hard to miss indentation, if anything, to the point that given a conflict between whitespace and a sea of brackets/braces my first instinct is probably to trust the whitespace. I don't think I'm alone in that.
        TheZenPsycho 13y ago
        so do you use tabs or spaces. or tabs AND spaces. Is that 2 spaces or 4? or did I accidentally put 5 in somewhere? is a trailing space going to cause problems or not? Text editors certainly don't help keep this stuff straight. I just don't think white space should be part of the syntax. It makes editing HARDER. not easier. And it's not even visible, unless I turn on a special feature in my text editor. I just don't know what exactly you YAML guys are smoking that you think it's easy or more humanistic.
  - theophrastus 13y ago
    Is the reason for "json5" understandable?
  - eropple 13y ago
    Hierarchical, supports comments for explanation of intent, is more supported than HOCON. Data type specifiers a major plus. I'll take all your suggestions.

stormbrew 13y ago

> Develop a coffescript like JSON precompiler with comments and trailing commas and all sorts of things like no quoted keys if needed but call it something different. Someone did, it's called yaml.

theg2 13y ago
And I still don't understand why you'd pick yaml over anything else out there.
- stormbrew 13y ago
  I pick it for config files humans have to write and read because writing and reading json as a human is tedious and error prone.
  - vertex-four 13y ago
    As someone who has to write yaml... writing yaml is significantly more error-prone than JSON. It has far more edge cases than JSON does.
    - stormbrew 13y ago
      I agree it has a lot of corner cases, but they are mostly in service of allowing for an uncluttered document. The fact that you can always write a subset of the document in json is helpful when things get hairy. But this is a thing that often gets ignored when talking about what humans are good at reading and writing. We aren't computers (or at least, we aren't as linear of computers). It's obvious enough in the languages that we speak and write every day with each other that we derive from and plant a lot of meaning in the margins of our expression. We tend to understand things quite clearly when noise has been elided out. A lot of JSON becomes pure noise: "{{[[{[{{[". Really, though, what I'm most in favour of is that now that we've agreed on a basic data model that is less insane than its obvious predecessors (ASN.1 and XML) it would be nice if applications with configuration opened themselves to allowing the user to decide the specific format for their own benefit. If it's TOML or JSON or JSON5 or JSON+comments (Sublime Text) or YAML or whatever, so long as it results in the same structure who cares?
      - TheZenPsycho 13y ago
        > A lot of JSON becomes pure noise: "{{[[{[{{[". I'd rather that be visible brackets than invisible whitespace.
        stormbrew 13y ago
        Why? Assuming 'invisible whitespace' in this context is actually a meaningful thing. I find it hard to miss indentation, if anything, to the point that given a conflict between whitespace and a sea of brackets/braces my first instinct is probably to trust the whitespace. I don't think I'm alone in that.
        TheZenPsycho 13y ago
        so do you use tabs or spaces. or tabs AND spaces. Is that 2 spaces or 4? or did I accidentally put 5 in somewhere? is a trailing space going to cause problems or not? Text editors certainly don't help keep this stuff straight. I just don't think white space should be part of the syntax. It makes editing HARDER. not easier. And it's not even visible, unless I turn on a special feature in my text editor. I just don't know what exactly you YAML guys are smoking that you think it's easy or more humanistic.
- theophrastus 13y ago
  Is the reason for "json5" understandable?
- eropple 13y ago
  Hierarchical, supports comments for explanation of intent, is more supported than HOCON. Data type specifiers a major plus. I'll take all your suggestions.