4 ms·

Wondering why there is no light-YAML or just JSON without comma and braces sort of language available? Or even if there why not popular yet? Almost everyone com

Wondering why there is no light-YAML or just JSON without comma and braces sort of language available? Or even if there why not popular yet? Almost everyone complains about the huge spec of YAML and that pretty much seems to be the biggest complaint (other than it getting huge - but that can be there for all languages).

thaumasiotes 6y ago
> Wondering why there is no light-YAML or just JSON without comma and braces sort of language available? Well, JSON without commas or braces would be restricted to single literal values. (Or, I guess, single-element lists, but what would the point of that be?)
- coldtea 6y ago
  Parent means YAML-like JSON-lite format, so you could have multiple elemnts without commas or braces, just with whitespace and newlines as separators. Where JSON here is just a stand-in for "simple format with few types", not about it being parseable as JSON or anything.
  - thaumasiotes 6y ago
    If all you have are record separators, so that the only data you can send is a list of values distinguished by nothing other than the order in which they occur, then the information about the structure of the data must exist separately on both the sending side and the receiving side. Better hope they agree. But regardless, I feel like that exists right now; doesn't this describe protocol buffers?
    - coldtea 6y ago
      Parent said no commas or braces. He didn't say "all you have are record separators". E.g.: a list: - foo - bar - buz and other things besides list of dicts: persons: - name: John Smith age: 54 occupation: Obergruppenführer - name: Frank Frink age: 32 occupation: craftsman (Those are already valid YAML iirc)
      - thaumasiotes 6y ago
        > Parent said no commas or braces. He didn't say "all you have are record separators". No, he didn't, he said "JSON without commas or braces". That makes no sense. You were the one who specified nothing but record separators: >>> you could have multiple elemnts without commas or braces, just with whitespace and newlines as separators. And sure, that approach has upsides and downsides compared to JSON, which is why it's already a widespread alternative to JSON. Your proposal here is just JSON that looks slightly different. The reason we don't have that is that we do have that, with isomorphic syntax, and we call it "JSON". There's nothing at all interesting about the idea of "JSON without commas" if you satisfy it by saying "we've eliminated the comma by relabeling it as a 'hyphen' in some cases and a 'tab' in the rest".
        coldtea 6y ago
        >No, he didn't, he said "JSON without commas or braces". That makes no sense. Strictly interpreted, no, it doesn't. But I picked his intention, and clarified it already as: "Where JSON here is just a stand-in for "simple format with few types", not about it being parseable as JSON or anything." to the comment you've respond to :-) >Your proposal here is just JSON that looks slightly different. The reason we don't have that is that we do have that, with isomorphic syntax, and we call it "JSON". There's nothing at all interesting about the idea of "JSON without commas" if you satisfy it by saying "we've eliminated the comma by relabeling it as a 'hyphen' in some cases and a 'tab' in the rest". Hey, one should at least try to infer what people mean from context. Not everybody is a native speaker or the best communicator. What the parent asks for, and it is interesting, and we should have had it, is basically "minimal, sane, YAML subset". TOML is somewhat it.
konjin 6y ago
I don't know about other but I have a nice little scheme based dsl which compiles to yaml for aws services. I've used it in anger for 2 years now and no one has noticed any difference at any place I've worked in.
coldtea 6y ago
>Almost everyone complains about the huge spec of YAML and that pretty much seems to be the biggest complaint No, the biggest complain about YAML is the type coercion, unexpectedly changing your data, and incompatibility between parsers and versions...
Cthulhu_ 6y ago
.ini or .properties files are still pretty straightforward. That said, just because a language has these features, doesn't mean you need to use them. A lot of these issues are in part the fact they're there, but also that people don't take a stand / don't have the discipline to NOT use them. It's why I'm now an opponent of Scala, because it's too free and feature rich.
cageface 6y ago
This is one problem that just goes away in lisp since data and code are in exactly the same syntax.
IshKebab 6y ago
TOML or JSON5 are probably the best options for this sort of thing at the moment.
wmil 6y ago
TOML is good. CSON is neat, but it never caught on (https://github.com/bevry/cson https://github.com/bevry/cson). There's a very specific, very common, use case that the people who write most markup parsers refuse to support... A good config file format needs to: - be human readable - be machine modifiable while preserving comments and whitespace - be unable to run code - be unable to call a constructor on an object without being whitelisted
- whizzter 6y ago
  It's really sad CSON didn't catch on. We have a JSON swagger spec at work and balacing braces,etc is just painful. So for a new project I tried writing a spec in YAML instead and the indentation rules felt quite shaky for me as a beginner (ie i wasn't entirely sure where things ended up with all the modes) so it was a lot of trial-and-error for someone unfamiliar with YAML as me (and it explains why I've kinda stayed away from it because writing it was as hard as reading it sometimes). CSON seems to have a sweet-spot between them with less clutter than JSON but more straightforward block rules than YAML.
southerntofu 6y ago
You mean something like StrictYAML? https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/
sofixa 6y ago
HCL is light JSON and works pretty well for configuration.
thu2111 6y ago
There is. It's called HOCON and I'm surprised it's not mentioned yet: https://github.com/lightbend/config/blob/master/HOCON.md https://github.com/lightbend/config/blob/master/HOCON.md HOCON is the "human optimised config object notation" and is a superset of JSON. All valid JSON is valid HOCON but then it goes and adds lots of other features specifically designed for writing usable config files.

thaumasiotes 6y ago

> Wondering why there is no light-YAML or just JSON without comma and braces sort of language available? Well, JSON without commas or braces would be restricted to single literal values. (Or, I guess, single-element lists, but what would the point of that be?)

coldtea 6y ago
Parent means YAML-like JSON-lite format, so you could have multiple elemnts without commas or braces, just with whitespace and newlines as separators. Where JSON here is just a stand-in for "simple format with few types", not about it being parseable as JSON or anything.
- thaumasiotes 6y ago
  If all you have are record separators, so that the only data you can send is a list of values distinguished by nothing other than the order in which they occur, then the information about the structure of the data must exist separately on both the sending side and the receiving side. Better hope they agree. But regardless, I feel like that exists right now; doesn't this describe protocol buffers?
  - coldtea 6y ago
    Parent said no commas or braces. He didn't say "all you have are record separators". E.g.: a list: - foo - bar - buz and other things besides list of dicts: persons: - name: John Smith age: 54 occupation: Obergruppenführer - name: Frank Frink age: 32 occupation: craftsman (Those are already valid YAML iirc)
    - thaumasiotes 6y ago
      > Parent said no commas or braces. He didn't say "all you have are record separators". No, he didn't, he said "JSON without commas or braces". That makes no sense. You were the one who specified nothing but record separators: >>> you could have multiple elemnts without commas or braces, just with whitespace and newlines as separators. And sure, that approach has upsides and downsides compared to JSON, which is why it's already a widespread alternative to JSON. Your proposal here is just JSON that looks slightly different. The reason we don't have that is that we do have that, with isomorphic syntax, and we call it "JSON". There's nothing at all interesting about the idea of "JSON without commas" if you satisfy it by saying "we've eliminated the comma by relabeling it as a 'hyphen' in some cases and a 'tab' in the rest".
      - coldtea 6y ago
        >No, he didn't, he said "JSON without commas or braces". That makes no sense. Strictly interpreted, no, it doesn't. But I picked his intention, and clarified it already as: "Where JSON here is just a stand-in for "simple format with few types", not about it being parseable as JSON or anything." to the comment you've respond to :-) >Your proposal here is just JSON that looks slightly different. The reason we don't have that is that we do have that, with isomorphic syntax, and we call it "JSON". There's nothing at all interesting about the idea of "JSON without commas" if you satisfy it by saying "we've eliminated the comma by relabeling it as a 'hyphen' in some cases and a 'tab' in the rest". Hey, one should at least try to infer what people mean from context. Not everybody is a native speaker or the best communicator. What the parent asks for, and it is interesting, and we should have had it, is basically "minimal, sane, YAML subset". TOML is somewhat it.

konjin 6y ago

I don't know about other but I have a nice little scheme based dsl which compiles to yaml for aws services. I've used it in anger for 2 years now and no one has noticed any difference at any place I've worked in.

coldtea 6y ago

>Almost everyone complains about the huge spec of YAML and that pretty much seems to be the biggest complaint No, the biggest complain about YAML is the type coercion, unexpectedly changing your data, and incompatibility between parsers and versions...

Cthulhu_ 6y ago

.ini or .properties files are still pretty straightforward. That said, just because a language has these features, doesn't mean you need to use them. A lot of these issues are in part the fact they're there, but also that people don't take a stand / don't have the discipline to NOT use them. It's why I'm now an opponent of Scala, because it's too free and feature rich.

cageface 6y ago

This is one problem that just goes away in lisp since data and code are in exactly the same syntax.

IshKebab 6y ago

TOML or JSON5 are probably the best options for this sort of thing at the moment.

wmil 6y ago

TOML is good. CSON is neat, but it never caught on (https://github.com/bevry/cson https://github.com/bevry/cson). There's a very specific, very common, use case that the people who write most markup parsers refuse to support... A good config file format needs to: - be human readable - be machine modifiable while preserving comments and whitespace - be unable to run code - be unable to call a constructor on an object without being whitelisted

whizzter 6y ago
It's really sad CSON didn't catch on. We have a JSON swagger spec at work and balacing braces,etc is just painful. So for a new project I tried writing a spec in YAML instead and the indentation rules felt quite shaky for me as a beginner (ie i wasn't entirely sure where things ended up with all the modes) so it was a lot of trial-and-error for someone unfamiliar with YAML as me (and it explains why I've kinda stayed away from it because writing it was as hard as reading it sometimes). CSON seems to have a sweet-spot between them with less clutter than JSON but more straightforward block rules than YAML.

southerntofu 6y ago

You mean something like StrictYAML? https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/

sofixa 6y ago

HCL is light JSON and works pretty well for configuration.

thu2111 6y ago

There is. It's called HOCON and I'm surprised it's not mentioned yet: https://github.com/lightbend/config/blob/master/HOCON.md https://github.com/lightbend/config/blob/master/HOCON.md HOCON is the "human optimised config object notation" and is a superset of JSON. All valid JSON is valid HOCON but then it goes and adds lots of other features specifically designed for writing usable config files.