8 ms·

In a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way int

In a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way into config files

deleted 2mo ago
[deleted]
an0malous 2mo ago
Seems more like the opposite vein, JSON's lack of comments or other affordances has kept it safe from footguns
- madeofpalk 2mo ago
  Of all the problems with YAML, how is comments a footgun?
  - an0malous 2mo ago
    > or other affordances
    - anonymars 2mo ago
      Well, while we're on the topic: "On the virtues of the trailing comma" https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=109379 https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=10...
  - frollogaston 2mo ago
    The idea is it makes people think they can use YAML for sketchy stuff as long as they comment on it.
  - snackbroken 2mo ago
    [dead]
xgulfie 2mo ago
I've seen people put "//" keys in their json lol
- stronglikedan 2mo ago
  It's not terrible as far as I know, and it's less ambiguous than putting a "comment" key. I like it!
- reddalo 2mo ago
  I've also seen using "__" as a key for comments. I think it's better because it doesn't need to be escaped.
- hutattedonmyarm 2mo ago
  There _is_ a json variant with comments, so that’s what you’ve seen. Not all parsers support that though
  - jeroenhd 2mo ago
    It's non-standard JSON, so you can probably just assume most patsers don't support any given commented parser. At least XML permitted comments, fhe shift to JSON on everything almost makes me nostalgic.
    - DenisM 2mo ago
      When you get too nostalgic just think back to XSD type system in Xquery. That should cure the nostalgia real fast.
  - xgulfie 2mo ago
    Are you denying what I've seen with my own eyes? I am saying it was an object like this: { "//":"make sure these are divisible by 8", "width": 640, "height": 480 }
    - wincy 2mo ago
      Not the person you’re replying to but you were clear in what you were describing. It seems like they were thinking of some json parsers that’ll ignore just straight up anything after // before a new line in JSON (looking at you visual studio). So a .NET dev who has never touched anything but Visual Studio may make comments in the appsettings.json for a .NET project and it made all my command line parsers throw errors. Thanks Microsoft.
tuveson 2mo ago
As a data/serialization format (the original intended use of JSON), I think no comments is the right choice, since adding comments introduces a bunch of questions about how comments ought to be parsed into a datastructure (or if they should be sent/(de)serialized at all). But for config files the lack of comments is the wrong choice, since typically you want to explain why things are set the way they are. The lack of ordering of entries also makes total sense for data/(de)serialization, but makes no sense for a config. I think the problem is people are lazy and just want to JSON.parse() everything, and used JSON in places it doesn't belong, like config files.
- frollogaston 2mo ago
  Many JS toolchains will take js files as config to alleviate this problem. Which is actually nice if you ever need dynamic configs, cause that means not using some forsaken DSL. It still evaluates to JSON in the end.

In a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way into config files

deleted 2mo ago

[deleted]

an0malous 2mo ago

Seems more like the opposite vein, JSON's lack of comments or other affordances has kept it safe from footguns

madeofpalk 2mo ago
Of all the problems with YAML, how is comments a footgun?
- an0malous 2mo ago
  > or other affordances
  - anonymars 2mo ago
    Well, while we're on the topic: "On the virtues of the trailing comma" https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=109379 https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=10...
- frollogaston 2mo ago
  The idea is it makes people think they can use YAML for sketchy stuff as long as they comment on it.
- snackbroken 2mo ago
  [dead]

xgulfie 2mo ago

I've seen people put "//" keys in their json lol

stronglikedan 2mo ago
It's not terrible as far as I know, and it's less ambiguous than putting a "comment" key. I like it!
reddalo 2mo ago
I've also seen using "__" as a key for comments. I think it's better because it doesn't need to be escaped.
hutattedonmyarm 2mo ago
There _is_ a json variant with comments, so that’s what you’ve seen. Not all parsers support that though
- jeroenhd 2mo ago
  It's non-standard JSON, so you can probably just assume most patsers don't support any given commented parser. At least XML permitted comments, fhe shift to JSON on everything almost makes me nostalgic.
  - DenisM 2mo ago
    When you get too nostalgic just think back to XSD type system in Xquery. That should cure the nostalgia real fast.
- xgulfie 2mo ago
  Are you denying what I've seen with my own eyes? I am saying it was an object like this: { "//":"make sure these are divisible by 8", "width": 640, "height": 480 }
  - wincy 2mo ago
    Not the person you’re replying to but you were clear in what you were describing. It seems like they were thinking of some json parsers that’ll ignore just straight up anything after // before a new line in JSON (looking at you visual studio). So a .NET dev who has never touched anything but Visual Studio may make comments in the appsettings.json for a .NET project and it made all my command line parsers throw errors. Thanks Microsoft.

tuveson 2mo ago

As a data/serialization format (the original intended use of JSON), I think no comments is the right choice, since adding comments introduces a bunch of questions about how comments ought to be parsed into a datastructure (or if they should be sent/(de)serialized at all). But for config files the lack of comments is the wrong choice, since typically you want to explain why things are set the way they are. The lack of ordering of entries also makes total sense for data/(de)serialization, but makes no sense for a config. I think the problem is people are lazy and just want to JSON.parse() everything, and used JSON in places it doesn't belong, like config files.

frollogaston 2mo ago
Many JS toolchains will take js files as config to alleviate this problem. Which is actually nice if you ever need dynamic configs, cause that means not using some forsaken DSL. It still evaluates to JSON in the end.